Hi all!
I'm thinking about going up to VCF in Wall next weekend. I haven't been
to it since it was the Trenton Computer Fest (think late 1990's) so I'm
not sure what the protocol is on tailgating, trading stuff or whatnot.
Appears that they have a "sale room" you drop things off in with prices.
Ok....
Things I could "sell" if anyone's interested:
HP1000e computer, dead power supply, basic boards, no advanced memory.
HP9825B likewise does not power up, but it's there.
Microvax 2 boards, stuff like that.
Spare 11/24 CPU boards (I have a bunch, all work, no idea why I have all
them)
Stuff I could bring to get out of my house and into the right hands:
Big box of pdp12 schematics. This came from my olden days when I had to
turn up a pdp12 because it will not fit in a station wagon. Still it
looks like board locations and a lot of 12 stuff. Big box, heavy to
ship, easier to drive over.
Ton of pdp8/12 IO cables. These are the black circular wire ones, I
think negibus. There's also some posibus ribbon cables but I'll save
those for my 8/L's. If you need a set, let me know.
Stuff I'd trade for:
AF01 A/D converter. I don't have Negibus anymore, but I did check/reform
the power supply and hooked it up and things do light up. Bunch of extra
channel cards (I think it might have all 64). Would trade for a memory
box for an 8/L.
Back to unearthing BLT.AI.MIT.EDU.......
C
I have a Quantum ATL-7100 100 tape DLT changer. Last I checked it worked
fine. It's almost as big as a fridge. I have around 100 tapes for it,
not all the same density. It uses fast/wide scsi-3 differential for the
drives. I think I have 2 working drives in the cabinet plus one or 2
separate external drives.
I think my drives are DLT-7000 or similar which gives a total capacity
of 7TB.
Upgraded with SDLT 220 drives and tapes the chassis would have a
capacity of 22TB.
Anyone interested in picking this up in South Jordan Utah? (outside Salt
Lake City).
The only issues I know about it, is the tape loading pivoting door is
not quite rotating correctly, and I replaced one of the AT power
supplies with a unit that is NOT autoswitching. So if you want to run
the unit on 220V instead of 110, you will need to change the chassis and
the replaced internal power supply.
It's really fun to load it up with tapes, then tell it to auto-shuffle
them. I have the door hot wired so you can open the door while it's
operating. Easy to restore the switch if you don't want to.
Photos here:
https://rikers.org/gallery/hardware-atl7100
Interested, please email directly, I don't check the list very often.
Tim
Hi all,
I?ve recently come across something i?ve soon realised really quite unusual. An RCA MS2000 MicroDisk Development System.
I?m very green to the COSMAC scene, with this being my first 1802 machine. I?m very interested in knowing the pitfalls i may come across in restoring such a machine. I?ve had a quick cursory look over the machine, and it seems to be complete, with 2 RAM/ROM cards, CPU card, FDC and a (3rd party?) ROM programmer board, along with the PSU and floppy disk drives.
It?s my understanding that these are pretty similar to the RCA Microboard development systems, which i believe are also pretty similar to the ELF ?homebrew? microcomputer this group revolves around. I?ve found some manuals on bitsavers,, a website on the Microboard system, along with disk images on the Emma02 emulator website, so I have a reasonable undertanding over what this actually is.
I have a week off work next week, so am planning on taking my time on disassembling and checking the unit over next week.
I?ll endevour to upload some pictures of said machine when i tear it apart.
Thanks,
Josh Rice
This is a long shot, but on the off chance anyone else on the list shares some of my particular weirdnesses, anyone got a line on the *patches* for Embarcadero (nee Borland (nee Starbase (nee Premia) CodeWright?
I have the latest version Embarcadero sold (and maybe still sells?) as of not all that long ago -- 7.5 -- but it's basically patch level 3 (e.g., 7.5.3) instead of patch level 5 (e.g., 7.5.5). I'm hoping someone has the patch installers squirreled away somewhere, and that I can find that person.
At least for Windows, patch installers were typically named something like "xcw753_4.exe", which would update an existing version 7.5.3 to version 7.5.4. Likewise xcw754_5.exe would update 7.5.4 to 7.5.5.
Every now and again, I go looking for archives in The Wayback Machine, etc. or stashed away versions of the patch installers, but no dice so far. I've even attempted emailing folks who posted 10+ years ago or more on various fora about the patches/about CodeWright, but nothing has yet worked out there either.
--
Daniel Moniz <dnm at pobox.com> [http://pobox.com/~dnm/]
Hi all,
you're invited to the Update computer club[0] public lecture series
"Updateringar"[1]!
When: 2022-04-09, 19:00 CEST
Where: https://bbb.cryptoparty.se/b/upd-0mo-m2u-aq8
A tour of Update's new premises
In December and January 2021/2022 Update moved out of the Uppsala
University IT department's basement into rooms of its own (thanks again
to all our volumteers who put in a huge effort!). The new premises offer
150 m? of space for Update's collection and activities, with a dedicated
area for exhibitions. What has happened since the move? With this online
tour we invite you to take a peek into our new home and at what we've
been working on in the last couple of months. We will give you an
insight into current and future projects and show off some of our
collection items.
Bjarni Juliusson, Anke St?ber (Update)
The lecture is free and open to everyone.
Don't want to miss upcoming events? Subscribe to our low-traffic
announcement list here[2]!
Hope to see you there,
Anke
[0] https://www.dfupdate.se/en/
[1] https://wiki.dfupdate.se/projekt:updateringar
[2] https://lists.dfupdate.se/postorius/lists/announce.lists.dfupdate.se
> the later "pdp11 bus hanbook" (which, as mentioned, does not seem to be
> online yet, alas)
Arck, I'm a moron; Paul has pointed out to me that this is, in fact, online
at Bitsavers:
http://www.bitsavers.org/pdf/dec/pdp11/handbooks/PDP11_BusHandbook1979.pdf
It didn't show up in a couple of pages of results in a Web search for it,
though.
I have noticed that things on Bitsavers often don't show up high up in Web
search results, unless you add 'bitsavers' to the search term.
I have been told that at one point Google was 'downgrading' results that used
plain HTTP, instead of HTTPS, because they were trying to push people to
switch to HTTPS (this was when everyone was hyperventilating over the Snowden
revelations). Given the near-ubiquitous use of HTTPS these days, I'd have
thought that piece of 'information credit engineering' by our tech overlords
was past its 'sell by' date, and now serves primarily to block people from
finding the material they are looking for (as here).
Noel
Continuing the debugging of my recently acquired PDP-8/E, I wrote an address
test that's easy to enter from the front panel:
---
# PDP8 Quick Address Test
# Pass 1: Loads locations 23-7777 with their own address.
# Pass 2: Tests each location for the correct address. If
# it fails (address does not equal it's own address) then
# the diagnostic halts with the error location in 22.
# The contents of that location displays the error.
# By Lyle Bickley
#
0000 7600 CLA
0001 1021 TAD 21
0002 3022 DCA 22
0003 1022 TAD 22
0004 3422 DCA I 22
0005 2022 ISZ 22
0006 5003 JMP 3
0007 1021 TAD 21
0010 3022 DCA 22
0011 1022 TAD 22
0012 7041 CMA IAC
0013 1422 TAD I 22
0014 7440 SZA
0015 7402 HLT (ERROR!)
0016 2022 ISZ 22
0017 5011 JMP 11
0020 5000 JMP 0 (START OVER)
0021 0023
0022 0000
---
Cheers,
Lyle
--
73 NM6Y
Bickley Consulting West
https://bickleywest.com
"Black holes are where God is dividing by zero"
> From: Paul Koning
> You might give a precise source citation on that page.
Done:
https://gunkies.org/w/index.php?title=UNIBUS_Initialization&curid=6842&diff…
Don't complain to me if the publication data is skimpy; that's all that's in
it! (I mean, we all know that DEC is in Maynard, but the book doesn't say it...)
Noel
So, I looked at the early editions of the "pdp11 peripherals hanbook", which
have good, detailed discussions of UNIBUS operations (at the back; chapter 5,
"UNIBUS Theory and Operation", in the 1976 edition), but in contrast to the
level of detail given for master/slave operations, and bus requests and
interrupts, the level of detail on power up/down is very low, especially
compared to that in the later "pdp11 bus hanbook" (which, as mentioned, does
not seem to be online yet, alas). So, I have transcribed that section, and
posted it:
https://gunkies.org/wiki/UNIBUS_Initialization
I have yet to scan and post the associated timing diagrams (which are useful,
but not critical); the desktop that runs my scanner is down at the moment,
alas. (If anyone who has a copy would like to volunteer to scan them, that
would be great.)
Noel
>From here:
https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=2096776#20…
They are bog standard Sun Enterprise systems, drive removed and destroyed
for privacy reason. They are only interesting for what they've done. By
university rules, our group can essentially "permanent loan" them to a
non-profit, but any sale or transfer of ownership is up to
University Excess and Salvage.
A bit of history disappearing, which is nothing new in this group.
On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech <
cctech at classiccmp.org> wrote:
> We need to onshore Nixie production now! ;-)
>
Gentle plug for https://www.daliborfarny.com/.
I have three AlphaServer 2100 systems in storage in the UK
(Oxfordshire). The storage, however, is due to be demolished (soon, but
no fixed date).
I won't have room to store these three systems, so if anyone would be
interested in offering them a home, then please get in touch!
I can probably get some pictures in the next day or two.
These systems were SMP Alphas and could sport as many as 4 CPUs. I'm not
sure of the configuration of these systems but I can probably find that
out soon.
They have not been run since ~2003 so they may be in need of some TLC.
OTOH they are not rusted to death so you have a chance of getting them
back to life.
Just so you know what you might be dealing with these systems are about:
700mm H x 430mm W x 810mm L.
I can't find the weight in any of my references right now but they are
very heavy. Three people can move them up a slight slope with some
effort but you would not successfully lift it into a car (assuming that
it would fit). I'm planning to dismantle them to move them (i.e. remove
PSU/PSUs etc. until they are light enough to move). A tail-lift would
probably be the sane way to go (and is, indeed, how they got to their
current location.
I'm hoping that someone can step forward and offer one or more of these
machines a new home. Please contact me off-list (once you're sure you
understand what you are getting into :-)).
Antonio
--
Antonio Carlini
antonio at acarlini.com
This may be of interest to some list members, particularly those who have an
interest in the BBC computer or just like Twilight Zone type stories.
Apart from being extremely interested in classic computers I also like the
old stories that surround these old machines. A while ago I stumbled across
a story about a BBC computer (this is the short version) that had been lent
out from a school l think (as they did in those days due to the cost of
machines back then) and this BBC, despite apparently not being connected to
anything, started displaying messages from the past (a previous land owner)
and someone in the future. As I said this is the short version of the story
- it's also referred to as the Dodleston Messages or even the Dodleston
Files if anyone wants to Google it. One of the claims was that this BBC
proved the existence of time travel - WOW, a big claim.
So the story eventually found its way into a book, The Vertical Plane by Ken
Webster (1989). I believe the book gets its title from the way scientists
describe time.
So being interested in the stories I started my world-wide hunt for a copy.
That was tough. A new copy unobtainable, an electronic copy not to my liking
- I like the real thing, used copies were monumentally expensive (apparently
the first edition was highly collectable). So I resigned myself to maybe one
day I would stumble across a copy in a used book shop or an Op Shop (aka
Thrift Shop) or a second hand shop. I visit these regularly because its
amazing what pops up in them.
Much to my surprise in February this year a Second Edition of The Vertical
Plane was published and of course obtained for me by my local bookshop.
My take - a good yarn - yes, do I believe the story - no.
Please note, I have no connection with the editor or the publisher.
Kevin Parker
Hello.
I have an HP 9000/217 (9817) machine that I'd like to install HP-UX 5.1 onto. In order to do this, I need to find the boot disk containing the correct kernel, which has the part number "A98680B", and is described as "Multi-user kernel for S200". Alternatively, I could run just the single-user version of HP-UX 5.1, which has the part number of "A98670B". The disk images for HP-UX 5.1 on bitsavers.org and hpmuseum.net do not have this disk.
I found these numbers in the HP-UX administrator manual. Page 370 lists the kernel disks and their contents.
http://bitsavers.org/pdf/hp/9000_hpux/1985/97033-90049_HP-UX_System_Adminis…
If anyone can point me in the right direction, it'd be greatly appreciated!
Thanks.
> From: "Rob Jarratt"
> I did plug the connector back in, so that DCLO and
> LTC are connected, I just removed the ACLO pin.
Ah, OK, good. Pulling the pins from those Mate-n-Loc shells without the right
tool is tricky; glad you did it, because as Brent Hilpert pointed out, having
a working DCLO is important, to reset everything to a known state on power-on.
> I didn't look for replacements last night. Is there a modern
> equivalent?
Not that I know of. Even if you found something with the same pin-out,
supposedly DEC selected ones that were 'good enough'. I've never had an issue
with NOS ones that I bought from vendors, though.
> I may have found a source of NOS.
Great; get several, they're a useful chip to have around; the QBUS uses them,
as well as the UNIBUS.
If the same place has DS8640's (the receiver), save on shipping (and ordering
delays) and get a couple of those too. I say that because depending on what
else you had plugged into the UNIBUS post ACLO failure, the -15V may have
damaged them too.
The M9312 (not sure if you had one of those, but the -11/24 manual says it's
common in them) uses ACLO (via a DS8640). The KY24 seems not to (as far as I
can tell from a quick look - negative results from a quick print scan aren't
100.00% reliable, whereas positive ones are), oddly enough. In EUB memory
(not sure which you have), the MS11-L and MS11M MS11-P don't seem to, whereas
the MS11-P _drives_ ACLO (through an 8881) - probably to prevent CPU startup
until the ECC is cleared). Etc, etc.
> I always marvel at how neatly those wires are done, I wish I knew how
> to do such a neat job.
The same way the old joke says one gets to Carnegie Hall, I expect! :-)
(I wonder what the UK equivalent of the Carnegie is - the Royal Albert,
probably?)
Noel
> The 'unused' gate in E52 is the one that the added wires from the ACLO
> ECO went to; I wonder if it was damaged by the -15V, somehow?
So, I checked, and the wire that goes from the plated-through hole next to the
etch cut on E70p1 winds up at E52p4 (the bus line on that transceiver),
thereby connecting the latter directly to UNIBUS ACLO (on pin BF1). So that's
almost certainly what caused other gate(s) in E52 to fail.
I think I have managed to trace where all the other two wires to that 'new'
gate in E52 went to/from, to see exactly what the ECO is. Given that E52 is a
transceiver, it was likely substituted for E70 so that the KDF11-U could also
_drive_ BUS ACLO.
I discovered that E52p5 (the new transceiver's input) is connected to E73p13
(an DS8640 quad NOR used as a bus reciver); that's in the upper left corner of
K2. It's BUS PB L NOR BUS PA H - i.e. a parity error has been detected in
memory - so it apparently then power-fails the system!
The incoming BUF ACLO (E52p6) goes to a PTH next to E70p8. On the bottom,
there's a trace from that PTH that goes to E66p13 - which is the inverter
shown on K2 which converts BUF ACLO H to POWER OK H. So that probably the
answer to my plaint about E70p1 being left floating: perhaps theres an etch
cut somewhere that disconnected E66p13 from E70p2, so the former can now be
driven by E52p6. I can't see one, but there's a trace from that latter PTH
that dives under E70, and I can't see it well, but it looks like it goes to
E70p2. It would be interesting to know what they did about the E70p2 -> E66p13
connection.
Noel
> does [disabling the MCLK counter via DCLO, asserted by the two
> E126 monostable chain from ACLO] happen just on power-down, or on
> power-up too? I'd need to understand how that two monostable chain
> works in both cases, which I currently don't. (I only understand
> monostables when pulses trigger them, not edges, which is a big part of
> why I don't completely understand it.)
So this was bugging me, so I hauled out my TI TTL databook and looked up the
LS123.
According to that, the 123 is triggered by the rising edge on the B
(non-inverted) input, when the A (inverted) input is low (which it will be
here; it's tied to ground). (Also by the falling edge on A when B is high,
which we can ignore.)
So I think that chain is probably triggered only on power-down, which will
produce a rising edge on P FAIL. (Power-up will produce only a falling edge
on P FAIL, once power is up and good.)
(Note that the second monostable is triggered, also on B, by the -Q output of
the first; i.e. by the 'falling' edge of the first's pulse. But see also at
the bottom, below.)
So that should happen (if I have correctly understood this, which is not
certain, I'm just a software person :-) is that some time after P FAIL goes
high - a delay set by the first 123 - the second 123 produces a pulse (of a
width set by its RC pair) - which via E52 produces an assertion pulse on DCLO.
WTF? (Not that we care in this machine's case, since i) it only happens on
power-down, and ii) it's just a pulse, so it's affect on MCLK will be very
transient; it can't cause it to stay off. My curiousity has been piqued, is
all. :-) The TM does not, after a _thorough_ search (although there are a few
mentions of power u/down, but not this), explin why, alas. (The TM for some
_other_ -11 CPU, one which contains a similar circuit might, but I'm not
_that_ curious! :-)
My _guess_ is that the intent is to reset all devices to a good idle state,
_before_ power actually goes out. (Don't ask me why it just doesn't use
INIT, though!)
The potential fly in the ointment of complete understanding is that a 123 can
_also_ produce a pulse on a rising edge at the clear input - and there is
some circuitry driving the clear input on the second 123. (The clear input on
the _first_ 123 seems to be left hanging in space - odd!) It seems to be set
off by the mysterious DGP03 signal, generated by the microcode - but the GP
table on pg. 4-21 of the TM doesn't contain an entry for '3'? Unless it has a
typo - there are two '5' entries. In which case it could be 'Toggle the HALT
flip-flop (K6)' (which I don't see on K6, unless it's E78) but yah, pulsing
DCLO will probably clear it, wherever it is!
This machine is making my head hurt.
Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if not,
then we'll have to work out why not.
Noel
When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells.
paul
> It was quite a struggle to separate those nylon connectors, is there a
> trick to it?
You mean the Mate-n-lok's? Not really; just make sure the catch is released.
What did you do about DCLO? (Oh, I think I see the answer, below.... looks
like you're relying on the pullup on K3...)
> When I powered on, the CPU LEDs did not light up.
Two of them ('0' and '1') are just bits in a special register, and thus only
do anything when the bootstrap code fondles them. When you get ODT running,
you can amuse yourself turning them off and on manually! :-)
> I did notice that the CLK LED flickered on briefly when I powered it
> off.
Interesting. Not sure exactly what we can deduce from that; but interesting.
> I put a scope probe on TP1 (p152 of the PDF), there was no activity,
> the pin remained high.
Yes; the signal there (MCLK H) is more or less the same one that drives the
'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the problem
space to a small part of K1.
> The problem now is that I expect I will need to probe various pins to
> find out what is going on. But I don't have a Unibus extender and I am
> reluctant to remove the backplane. From what I can tell in the
> Technical Manual you can't install the CPU in other slots
Basically right; the backplane and CPU are designed to have it go in slot 1.
It _might_ work in other MUD slots, with some loss of functionality (e.g.
slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map board
pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to
chance it, there might be a clash.
> I am forced to tack solder probe wires to the chips, which works but is
> time consuming. Any other ways?
Sorry, I don't have any experience to suggest any; too well supplied with
extender cards, so I've never had to resort to alternatives!
> I *think* I have found something. There could be a fault in E52 (sheet
> K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF
> DCLO H at an average 1.64V
Yeah, that's wrong. E52 is bad, and will have to be replaced.
(From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on the
UNIBUS, with the resistor network on the M9302, should be about 3.5V - but now
I'm confused, even with the P/S connector unplugged, it should still be 3.5V
or so. Oh well, it's late, the brain is powering down... :-)
The 'unused' gate in E52 is the one that the added wires from the ACLO ECO went to;
I wonder if it was damaged by the -15V, somehow?
> logical 0 output should be 0.4V max
Which is what you should be seeing.
> I also measured K6 BUF DCLO L to be always low, suggesting it thinks
> the K6 BUF DCLO H is a logical 1.
Yup; and that definitely explains why the clock isn't running - BUF DCLO L is
clearing E41 on K1.
Anyway, you'll have to replace E52 (which will be a bit of a pain, with the 3
ECO eires tacked to it). The DS8641 is an old chip, no longer in production, so
the usual suppliers may not have it, but there are some on eBait.
Noel
Finally found time to get to this one...
> From: Rob Jarratt
> However, there is a puzzle. On the CPU I found that the track from the
> pull up resistor to E70 has been cut.
I don't know about the "pull up resistor" part, but I have several KDF11-U's,
and _all_ of them have the trace on the bottom of the card connected to pin 1
of E70 cut, in the exact same place (about 1/8" from the pin). This suggests
that it's not a local mod (as you suggest below), but an 'official' DEC ECO.
> This would suggest that E70 pin 2 is floating, which I think means that
> K2 BUF ACLO H is also floating
The input (pin 1) will be floating, but not the output (pin 2); TTL doesn't
work that way, I think. I may have this wrong, but I think open TTL inputs
float high, so BUF ACLO should be low. I looked, and I don't see any other
traces (e.g. on the top side) going to pin 1. So I'm a bit puzzled that DEC
allowed that input to float, as open inputs can lead to erratic operaton;
they're usually tied high, or to ground.
> K2 BUS ACLO L however has been patched to E52 pin 4, which is the
> output of a gate on sheet K6. Can't say I understand why.
Me neither; that's an unused (on the prints) driver in the DS8641 (center
bottom of the page) - although that gate seems to have been fully wired up
(wires to pins 4, 5 and 6) as part of the ECO.
There is an ECO list on pg. 167 of the -11/24 prints (2 pages after K14),
but I don't see an E52 in it anywhere.
The puzzle here, if E70p1 is cut, and the output is low, is why the CPU clock
isn't running. The -15V on BUS ACLO shouldn't have taken out any other
semiconductors; it's not attached to anything else.
(It will have run C6, on the lower right of the card, the wrong way, but i) I
think that's a non-polarized item - and 100V rated, per the prints, and ii) I
don't think that goes anywhere else, even if it's not.)
So what's stopping the clock from running, then?
Noel
> From: Tony Duell
> A short in FET Q15 on the bias/interface board in the PSU could do it.
> The gate of that FET is driven from an LM339 comparator the -ve supply
> of which is -15V.
Ah; I hadn't even looked at the P/S prints.
(Like I said, I'm really weak on analog: for digital, I have the advantages
that i) although I'm basically/mostly a software person, the MIT CS
department is part of the EE department, and they made sure that all the CS
people had a decent grounding in the fundamentals of digital hardware; and
ii) in my early years, I was involved in a number of actual hardware
projects, including a UNIBUS DMA network interface that tuned into an actual
product. So I'm pretty good with a digital circuit diagram, like these CPU
prints. But analog stuff is still a mostly-closed book to me! :-)
Anyway, I'm happy to let you provide the analysis of the P/S... :-)
> From: Rob Jarratt
> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
> did).
I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
1K pF cap there (the purpose of which I still don't understand, unless it's
just a smoother). Although I suppose that if that cap failed, shorted, maybe
that could have taken out Q15 somehow.
> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
> the same connector
Now why didn't I think of just un-plugging that whole connector! Duhhhh! My
only concern would be leaving inputs floating...
DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
too lazy to work out what leaving that input floating will do, and, if it has
bad consequences, trace out all the places it goes (it should be connected up
to cause an interrupt, somewhere), but there's no point; the KW11 has an
'interrupt enable' that has to be set by software before it can do anything;
so at the moment it's safe to just ignore it for now, and stay with a focus on
getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
pull-up on the M9302 for it the way there is for ACLO & DCLO.)
So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
(Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
If yes, great, go check the main CPU clock.
If not, time to i) see how far the rot has spread (e.g. have other gates in
that package died - not sure what else is in there; not just looking at things
connected to the output - on pin 2), and ii) decide how to repair or
temporarily bypass. (Ditto for anything else that got taken out.) I'd be
tempted to bypass it (since I doubt you stock 8837's - although I do :-) -
ACLO handling isn't needed to get the CPU running. Tie BUF (not BUS!) ACLO to
ground, I'd say, and we can move on to look at MCLK.
> If that works then I think repair ACLO and see if anything on the CPU
> is bad or anything else that might cause a short on the ACLO signal of
> the bus.
Well, your call, but i) working ACLO isn't needed to get the CPU running -
and, in particular, to look for other problems that might be preventing it
>from running, and ii) fixing ACLO isn't guaranteed to make the CPU work.
I'd recommend 'keeping the eye on the ball', and focus on the main CPU clock,
getting ODT running, etc. The ACLO issue(s) can be cleaned up at your leisure.
Noel
> and there is some circuitry driving the clear input on the second
> 123.
Never mind this section. I mis-read the print; the clear input is connected to
an _input_ of the flop below (which is also tied high).
Noel
> From: Brent Hilpert
>> ACLO is only used to trigger a 'power-failing' interrupt; CPU
>> operation is otherwise un-affected by ACLO (so the CPU can get ready).
>> DEC P/S's carefully sequence ACLO and DCLO such that on power-down,
>> ACLO is asserted first (to allow the CPU to get ready); on power-up,
>> DCLO is de-asserted first (the later de-assertion of ACLO is the
>> signal for the CPU to start running).
> a) "ACLO is only used to trigger a 'power-failing' interrupt"
> b) "ACLO is the signal for the CPU to start running"
> Only a, or a & b?
Sorry, I tried to write only 10 words, when I should have just bitten the
bullet and written 40.
There are two different circumstances: i) AC power coming on, and ii) AC
power going off. (Sorry if you already know this next, but I'm not skipping
anything any more: DEC paid careful attention to both, as the PDP-11's were
always intended to be able to deal well with un-attended operation over an
un-expected power outage. So they had to shut down in an orderly way on ii),
and start up in an orderly way on i). Having the operator press a 'reset'
button after power-on was not an option! Of course, the software had to be
written to handle it all, and not all of it did so; e.g. UNIX V6 didn't deal
well with either, whereas RSTS-11 would go through an outage and
automagically pick up exactly where it was when power went down.)
So when I said "ACLO is only used to trigger a 'power-failing' interrupt",
the un-stated circumstance was 'when AC power goes off'.
The bit about "de-assertion of ACLO [on power-up] is the signal for the CPU
to start running" is something I hadn't known, but just picked up (it's not
anything I ever had to pay attention to before) from reading the
"Initialization" section in the "pdp11 bus handbook" - which is not (alas)
online. (Maybe I should scan, OCR and port that section; it's fairly short.)
(There _is_ a "pdp-11 UNIBUS Design Description" document online:
http://www.bitsavers.org/pdf/dec/unibus/UnibusSpec1979.pdf
but alas it doesn't have anything like the detail given in the "pdp11 bus
handbook". 2.5 there, "Initialization Section", has some text about ACLO,
DCLO and INIT (which is generated by the CPU, not the P/S), but not much.)
Here's what the "pdp11 bus handbook" says (pg. 54):
"When [the processor] senses the negation of ACLO, [which happens after the
negation of DCLO, which itself happens "5 useconds after DC power is within
specifications" - i.e. plenty of time for all logic to reset itself to a
known state, after good power is available to it all] the processor starts
its power-up sequence."
How that happens in the -11/24 I'm not sure; the -11/24 TM doesn't cover it,
and the Fonz, which we don't have documentation on, will be involved.
> Now these things may well not be a problem here; I'm just looking for
> potential failure points because we're looking for an unknown fault by
> isolating things, and it's best done without introducing new potential
> problems, or at least being aware of the potential.
Makes sense.
> ACLO exercises influence over DCLO and hence the CPU clock via those
> those monostables (we both) mentioned earlier.
Right, I had forgotten about those - it was late, and my brain was shutting
down as I was tired.
> ACLO -edge:
> ==> inverted (E70.2/K2) to +edge
> ==> triggers FF (E67/K2_PFAIL) to latch high
> ==> triggers MonoFF (E126/K6_AC_TIM)
> ==> triggers MonoFF (E126.10-5/K6)
> ==> asserting K6_BUF_DCLO_L for some period
It's not clear to me what the _point_ of that all is; I had previously
guessed that "there's a delay between the PFAIL H input .. and _the CPU_'s
assertion of DCLO - i.e. if the P/S goes bonkers and indicates ACLO, and
doesn't promptly (after a suitable short delay to allow for power-fail
action) follow it with DCLO, as it is _supposed_ to, the CPU will indicate
DCLO on its own - and do it on the bus so everbody else will freeze too."
That might still be correct - I think that perhaps that path through the
monostables only operates on power-down (but maybe I'n wrong there, I don't
really understand completely how that all works) - on power-up, PFAIL H is
going to be a falling edge - so will the two E126 monostables just ignore
that? Alas, the -11/24 TM doesn't cover this, as far as I could find.
AC TIM winds up being used on K1, on the monostable at top right, which I
think generates a bus INIT pulse, when called for by the microcode (MIB14).
No idea why they need AC TIM to clear that monostable.
> ==> which disables MCLK counter (E41/K1)
Right, but does that happen just on power-down, or on power-up too? I'd need
to understand how that two monostable chain works in both cases, which I
currently don't. (I only understand monostables when pulses trigger them, not
edges, which is a big part of why I don't completely understand it.)
> It may be that it just stops the clock temporarily: DCLO asserted resets
> E67/K2_PFAIL, clearing it to register another ACLO / P FAIL.
Could be; that's something else I don't understand completely; that flop's
clear input depends on part on DGP06, which comes out of the E46 decoder on
K1, which is again driven by the microcode. I'll have to look at the TM, and
see if it explains that.
> I thinks he's right to poke around the clock circuitry looking for
> where the clock is being inhibited.
Yup. I was hoping that if we just disconnected the busted ACLO, the clock
would spring to life, and then we could move on to the next step(s), but
maybe looking into that block in detail, e.g. to see if E41 is being reset by
DCLO, would be the best way to go.
Noel
> From: Brent Hilpert
> DCLO & ACLO behave as power-on-reset signals to the system.
Minor nit: actually, I think it's DCLO which performs that function in a lot
of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
usually in buffered form, is used more widely for this function, but I doubly
digress in that observation.)
As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC P/S's
carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
(the later de-assertion of ACLO is the signal for the CPU to start running).
However, you make a good point with:
> If they are allowed to just float up as the power supply comes up you
> have no guarantees as to the end result ('end' meaning the state of
> things after the power supply has come up)
DEC specs state that DC power has to be up and stable 5 usec before DCLO can
be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
everything is in a known state when operation commences.
So I guess I'll go back to my original suggestion: disconnect the ACLO from
the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
everything to a known state on power-on, and then you can see see if E70 has
been fried, or is still working.
> Manually connecting/disconnecting bus-ACLO to GND after power-up will
> ... disable the clock.
I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
where all the clocks are generated, that looks at ACLO, or its inverted form
POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
of K2)? Did I miss something? All I can see is DCLO.
I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see
definitively what it does do; tomorrow.
Noel
> From: Brent Hilpert
> So apparently I've been looking at the wrong +5V supply (H777) because
> the rest of you are indeed looking at a different +5 supply (H7140),
> both of which are in that same 11/24 pdf document
That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140
is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably,
covered in the -11/24 print set.
> I really wish when people are asking for assistance or talking about a
> schematic or circuit they would include a link/reference to exactly
> what they are looking at
But everone probably _was_ looking at the same document - just different
pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the
print set' identifier. Still, one could say 'page xx of the PDF'.
Noel
> From: Rob Jarratt
> I found these two signals and ACLO is low (-15V)
'Good news, bad news'...
Bad is that something is seriously wrong there; 'allowed' values are 0v
(asserted) and +3V (un-asserted). I'm worried that the -15V will have taken
out some of the semiconductors that are 'listening' to ACLO (like E70, page
K2 of the CPU prints, lower right corner) - and possibly some of the things
that are connected to _them_.
Good news is that i) this would definitely cause a problem, so we're closing
in, and ii) even better, the machine doesn't actuallly _need_ the ACLO (or
DCLO) signal from the P/S to function properly. Just disconect them (which may
be a bit tricky; IIRC you've got a BA11-A - but you can pull the pin in the
connector shell of the power harness from the backplane, details of that here:
https://gunkies.org/wiki/DEC_power_distribution_connectors
or, worst case, just cut the yellow wire to pin 4 of the 6-pin connector). At
that point the pullups on ACLO (on the M9302 and the CPU - page K3 of the CPU
prints - that's odd, there's a pullup to +5V there, but a cap to ground; the
M9302 does indeed have the pull-up/down resistor pair on both ACLO and DCLO)
should pull ACLO high and the clock should now run (CLK LED on) - unless the
-15V killed something.
If the machine then runs, it's up to you as to whether you get the P/S
repaired so that ACLO work properly - your call. (I wonder how the -15V got
to ACLO - I suspect a solder bridge from the prior repair - but knowing the
answer is not important to getting the machine running.)
> DCLO is high and the DC ON light is illuminated
Good.
> the CPU doesn't do anything presumably because ACLO is asserted.
Yes. As long as the CLK LED is off, the machine will definitely be totally
dead. If you can get it on, ODT should run (modulo issues yet to be sorted
about the minimal functional machine - I'll post on that in a moment).
Noel
I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I posted
about it here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/
I have since had the PSU fixed again and it came back a couple of weeks ago.
When I installed it and applied power to the input, I heard a reassuring
relay click.
So I powered it on. The fans turned, but there was a crackle and I smelt
something burning. I couldn't locate the smell, there were no lights on the
CPU board, but the fans continued to turn.
I had to leave it a few days and today I went back to it to check things a
bit more carefully. All the power outputs of the PSU appear nominal.
However, the ripple seems quite high, with an amplitude of 600mV on the +5V
output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg.
The DC ON light comes on, but the M7133 CPU LEDs show no activity
whatsoever.
There is no apparent damage to the CPU or to the M7134 that was also
installed. So, I guess the component that blew up must be inside the PSU.
Presumably, whatever the part is, it is stopping the CPU working, because
previously the CPU did appear to show some activity, although of course it
could still be a failure on the CPU. I am not sure what other outputs the
CPU might depend on. There is the LTC signal for the line time clock, but I
don't know if its absence would stop the CPU working. I have not been able
to test the LTC signal as yet.
Can anyone suggest what else the CPU might need? Or is it LTC?
Regards
Rob
Its 600mV, but it is more of a spike than a ripple. Here is a trace: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg
Regards
Rob
> -----Original Message-----
> From: Wayne S <wayne.sudol at hotmail.com>
> Sent: 28 March 2022 23:15
> To: rob at jarratt.me.uk; Rob Jarratt <robert.jarratt at ntlworld.com>; General
> Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
> Cc: Chris Zach <cz at alembic.crystel.com>
> Subject: Re: PDP 11/24 - A Step Backwards
>
> How bad is the ripple?
> Anyone on the list know what?s acceptable?
>
>
> Sent from my iPhone
>
> > On Mar 28, 2022, at 14:46, Rob Jarratt via cctalk <cctalk at classiccmp.org>
> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Chris Zach
> >> via cctalk
> >> Sent: 28 March 2022 20:57
> >> To: cctalk at classiccmp.org
> >> Subject: Re: PDP 11/24 - A Step Backwards
> >>
> >>> I don't think the CPU is working at all. The reason being that there
> >>> is absolutely no LED activity. Including an LED that is supposed to
> >>> indicate a clock. Having hopefully eliminated all the power voltages
> >>> it left me wondering if there was a fault on the CPU or in the PSU.
> >>> Having had activity on those LEDs recently it seems most likely that
> >>> it will be the PSU, particularly as *something* in there blew up.
> >>> The only signal that I can identify that seems likely to have this
> >>> kind of effect is LTC, but I don't know enough about LTC to know if
> >>> its absence could cause the CPU board not to work at all, although I
> >>> see above that you think it unlikely. I suppose the fault could be
> >>> something I can't see on the CPU board, particularly as there do
> >>> seem to be some quite large spikes, otherwise I am not sure if there
> >>> is anything else from the PSU that could prevent the CPU getting going.
> >>
> >> I'm on a nice long train trip right now but I recently got my 11/24
> >> running again. One thing that baffled me was it would not do anything
> >> on the serial port. No ODT, no nothing.
> >>
> >> Turns out you really need to make sure the slots are filled properly.
> >> The CPU top, then the memory map, then for the next 4 boards one has
> >> to be either a properly configured MS11-PL (the 128kw board) or the
> >> memory boards specific to that type of 11/24. Or you have to put
> >> G7273's in the CD slots.
> >>
> >
> > I have been reluctant to put everything back in, in case the PSU fries
> something. And the ripple I noticed is certainly something that bothers me.
> Previously I had a burning smell from the memory board. I have since
> replaced all the electrolytics on the memory board, but I have not tried
> putting it back in the machine since. Just checking my notes, it seems I have
> had *intermittent* lack of activity on the CPU LEDs before, so it may be
> worth trying to put everything back in, although the ripple makes me
> hesitant to do so. For the record, right now I have only the M7133, M7134
> and G7273 installed.
> >
> >
> >> Next you need proper devices or G7273's in the next two slots and a
> >> proper terminator in the left sockets of the last slots and a G7273 in the
> center slots.
> >> Only then will ODT work.
> >>
> >> Another oddity is that the 5.25 inch box has +5 and +12 I think and
> >> the
> >> 10.5 has +5 and +15. There are different memory boards that work in
> >> one and not the other, or both depending on jumper settings that have
> >> to be right. Unibus drives me bonkers sometimes with the number of
> >> different voltages requires (+5, +12, +15, +20, -15, etc....) It
> >> doesn't help that the +15 and +12 are on the same pins.
> >>
> >> Plus it's possible someone screwed with some switches, make sure they
> >> are set properly (ie: default is a good start).
> >>
> >> If you're still stuck next week drop me a line and I'll fire up my
> >> 11/24 and see if I can replicate your failure.
> >>
> >>>
> >>>>
> >>>> The first will tell you that i) the CPU is basically functional,
> >>>> executing
> >>> micro-
> >>>> instructions, etc; ii) that the bus is basically functioning (for
> >>> master-slave
> >>>> cycles; DMA and interrupts will remain to be checked out); iii)
> >>>> that the console port is working. (Yes, on the KDF11-U, the console
> >>>> is on an
> >>> internal
> >>>> bus, and so in theory a machine could have the ODT 'front panel'
> >>>> working, _and_ still have a problem with the bus, but depending on
> >>>> the exact details of said problem, maybe not.)
> >>>>
> >>>> So, hook up a console, set the machine to 'halt', and power on. Is
> >>>> console ODT working? If so, congrats, you win, go to stage ii) below.
> >>>
> >>> I had a console attached. There is nothing on the console. When I
> >>> first got the machine I did get output on the console. But that was
> >>> before the PSU first failed on me, which is quite a few years ago now.
> >>>
> >>>>
> >>>> If not, you have a reduced area in which you have to investigate -
> >>>> and
> >>> you'll
> >>>> need a 'scope of some kind to make any progress. (If you don't have
> >>>> one, you're SOL. Get one.). In order i) is the CPU's internal clock
> >>>> (and thus, probably the microcode) running? (At this point you will
> >>>> need to consult
> >>> the
> >>>> "PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it
> >>>> trying to
> >>> talk
> >>>> to the console's registers? (See Section 4.6 of the TM, "Internal
> >>>> Address
> >>>> Decode".) If so, is the UART working properly? (4.7 of the TM,
> >>>> "Serial
> >>> Line
> >>>> Units".)
> >>>>
> >>>> If so, console ODT is running, you're now at stage ii): you can see
> >>>> if the
> >>> CPU
> >>>> will run. Deposit a 0777 ('BR .') in a likely location (I usually
> >>>> use
> >>>> 0100 or 01000); read it back to make sure the write succeeded. (If
> >>>> not,
> >>> likely
> >>>> either the UNIBUS or the main memory has a problem.) Start the
> >>>> machine; the 'Run' light should come on - if you're lucky!
> >>>>
> >>>> Depending on which bin you wound up in, further assistance s
> available.
> >>> :-)
> >>>>
> >>>> Noel
> >>>
> >
> From: Brent Hilpert
> But the LED and CPU clock are not driven directly by that RC oscillator
> - there's a bunch of logic in-between the oscillator and the LED / CPU
> clock.
Oh, sure; it was late (for me; the dog woke me up at AM today :-), and it had
taken me a while to get even that far (find the freakin' thing), so I just
wanted to pass the ball forward and crash!
I saw the "STOP OSC H" signal feeding into the production of "PRE OSC L", but
couldn't fully work out all the things that fed into that - and it now looks
like that's not an important thing anyway, "MCLK H" is the one to look at.
> [RC clock] => K1 OSC H/L
> --> [4-bit counter w parallel load] => K1 MCLK H/L
> --> LED
It seems to me that the LED, being driven directly by MCLK L, should be
flashing at the basic clock rate (i.e. dim to the eye) - so if it's totally
off, MCLK L must not be running. So that's thing absolutely numero uno to
investigate.
> --> [driver] => K1 CHIP CLK H (fonz CPU clock)
Yeah; the Fonz also gets "MCLK L" on pin 19, though - not sure what that's
for. Eh, not important at the moment.
> The 4-bit counter looks to be generating some additional phases
Yeah, section 4.2 "Timimg" of the -11/24 TM talks about all the various
clocks in some detail.
> but it's also controlled by a bunch of other signals. One of those
> signals is K6 BUF DCLO L which can hold the counter in reset, i.e.
> disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived
> on-board from K2 P FAIL H
Huh? BUF DCLO L is just BUS DCLO L, run through that DS8641 bus transceiver.
But yes, because DCLO can stop the clock, checking ACLO and DCLO is priority
numero uno in the debugging process, now. (Contrary to my previous fear, the
CPU might be OK, and it might just be a power supply issue.)
> which is derived from K2 BUS ACLO L
I haven't bothered to check to see where BUF ACLO L (generated on K2) goes,
but I assume it's used in power-fail trapping stuff. (ISTR that PDP-11 PS's
sequence ACLO before DCLO, to allow power-fail trapping, before the machine is
frozen as DC power actually goes low.) Likewise, not important at the moment.
> which is input from BF1-in-funky-hex-box which I presume is a bus
> connector pin.
Yes; the ID ("BF2") is an indicator to that.
> Even if ACLO is good, there's a whack of logic on the CPU board -
> including two monostables - just to get from ACLO to DCLO
The import of those two monostables isn't completely clear to me. However,
notice that the output is fed through the DS8641 bus transceiver to _drive_
BUS DCLO; my _guess_ is that there's a delay between the PFAIL H input (which
comes from BUS ACLO L) and _the CPU_'s assertion of DCLO - i.e. if the P/S
goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short
delay to allow for power-fail action) follow it with DCLO, as it is
_supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus
so everbody else will freeze too.
Anyway, I think we've got as far as we can until ACLO and DCLO are checked.
I'm upgrading the CHWiki KDF11-U page to cover the stuff that's not in the
CPU chapter of the -11/24 TM, like the meaning of those on-board LED's, etc.
Noel
> From: Rob Jarratt
> today I went back to it to check things a bit more carefully. All the
> power outputs of the PSU appear nominal.
> ...
> Presumably, whatever the part is, it is stopping the CPU working,
> because previously the CPU did appear to show some activity, although
> of course it could still be a failure on the CPU. I am not sure what
> other outputs the CPU might depend on. There is the LTC signal for the
> line time clock, but I don't know if its absence would stop the CPU
> working. I have not been able to test the LTC signal as yet.
> Can anyone suggest what else the CPU might need? Or is it LTC?
I'm going to start with some meta-comments, and then add some practical
suggestions for how to proceed.
Reading this, I'm guessing that you're a software person, right? Not that
there's anything wrong with that (_I_'m basically a sofware engineer), but if
one is going to collect and run (which inevitably means maintain/repair - it
was ever thus, including BITD) vintage computers, you need to have mildly
decent hardware skills. Yes, to some degree, one can lay this off on others
(as has been done here with the power supply - something I'd do myself, as my
analog skills are not very good), but I think developing some decent digital
hardware understanding would really help.
For instance, take your question about the LTC. To some degree, a complete,
entirely accurate answer is dependent on the details of the software
(bootstrap and/or OS). However, knowing how the LTC works, what the low-level
details are of what the CPU hardware does with it, etc would tell you whether
it is a cost-effective (in terms of overall 'getting the hardware working'
project) thing to spend time on looking at, to begin with.
(Parenthetical observation: I reckon that debugging _any_ issue, hardware
_or_ software, is a process of 'what's the _cheapest_ [easiest, quickest,
etc] test I can do that will produce the _maximal_ reduction in the area that
the bug could be in. Rinse, repeat, until you've tracked the problem to its
lair.)
(You may discover, once you get the machine mostly working, that the LTC
_specifically_ isn't working - at which point you can dive into it in detail.
But until then, I'd ignore it. It's a relatively small aount of stuff, and the
chance of a problem in there is small. And even if it's broken, the likely
effects are small. There are better things to look at - below. Having a clear
understanding of the machine's major functional units, and how they interact,
would have made that clear.)
So, in addition that that overview of the major functional units, you
definitely need to know how the QBUS works (read the QBUS chapter in the
"Microcomputer Products Handbook" or the "Microcomputer Processors"
books). (Yes, I know, the -11/24 is a UNIBUS machine, but the two busses
differ only in extremely minor details; if you fully understand one, you can
learn the other in half an hour. And the -11/24's CPU is a KDF11 CPU, and uses
the microcode ODT 'front panel' of the QBUS CPUs.)
Having said that, and starting with the "All the power outputs of the PSU
appear nominal" (which rules out a large area), this is the process I'd
follow to reduce the area the problem is in as quickly as possible. (And
maybe I should transform this into a 'fault analysis of QBUS (and some
UNIBUS) PDP-11 systems' on the CHWiki.)
You need to see if the CPU is _basically working. Two stages to that: i) is
the ODT 'front panel' (in microcode) working, ii) is the CPU basically
functional - i.e. can it fetch and execute instructions. Answers to those
will greatly reduce the area in which the problem (if there's _only_ one - a
possibility one must keep in mind).
The first will tell you that i) the CPU is basically functional, executing
micro-instructions, etc; ii) that the bus is basically functioning (for
master-slave cycles; DMA and interrupts will remain to be checked out); iii)
that the console port is working. (Yes, on the KDF11-U, the console is on an
internal bus, and so in theory a machine could have the ODT 'front panel'
working, _and_ still have a problem with the bus, but depending on the exact
details of said problem, maybe not.)
So, hook up a console, set the machine to 'halt', and power on. Is console ODT
working? If so, congrats, you win, go to stage ii) below.
If not, you have a reduced area in which you have to investigate - and you'll
need a 'scope of some kind to make any progress. (If you don't have one,
you're SOL. Get one.). In order i) is the CPU's internal clock (and thus,
probably the microcode) running? (At this point you will need to consult the
"PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it trying to
talk to the console's registers? (See Section 4.6 of the TM, "Internal
Address Decode".) If so, is the UART working properly? (4.7 of the TM,
"Serial Line Units".)
If so, console ODT is running, you're now at stage ii): you can see if the
CPU will run. Deposit a 0777 ('BR .') in a likely location (I usually use
0100 or 01000); read it back to make sure the write succeeded. (If not,
likely either the UNIBUS or the main memory has a problem.) Start the
machine; the 'Run' light should come on - if you're lucky!
Depending on which bin you wound up in, further assistance s available. :-)
Noel
> From: "Rob Jarratt"
> Thanks for the lengthy reply.
Glad to help - or try to.
> As an aside I have also been trying to find a fault on a Pro 350 which
> uses the same CPU chipset. I have a pinout but no datasheet.
There doesn't seem to be as lot on the F-11 set. I looked in the DEC
semiconductor handbook, and it's not there - although perhaps it
had been dropped by the one I looked at (which was mostly uVAX stuff)
as obsolete?
If you look in the KDF11-A and KDF11-U Tech Manuals, there is a chapter on
the F-11 chip set, as used in those cards, and that's better than nothing -
it talks a fair amount about the low level details of how the various chips
operate and interact, etc.
> I don't think the CPU is working at all. The reason being that there is
> absolutely no LED activity. Including an LED that is supposed to indicate
> a clock.
Looking at the KDF11-U prints, I finally found that LED (it's pretty low
level - I was worried that it might be a bit in a register, and driven by
software, but it's not, it's actually driven directly by the the CPU's
internal clock signal; it's on page K1 of the prints, 'Clock, State Decode',
in the very upper left corner). (The source of the CPU's internal clock is
just an RC circuit, in the lower middle of that page, and the trim pot that's
part of it - along the upper edge of the board - can be adjusted to set the
clock speed 'properly', per the note at the back of the prints on the page
which lists the configuration switches. The 2MHz crystal along the upper edge
drives the baud rate generator.)
> Having hopefully eliminated all the power voltages it left me wondering
> if there was a fault on the CPU or in the PSU.
If ODT isn't running, the problem is almost certainly in one of those two
areas.
> Having had activity on those LEDs recently it seems most likely that it
> will be the PSU, particularly as *something* in there blew up.
I'm not so sure. Those boards mostly just want +5V; looking a bit more, the
CPU chips do seem to use +12V. The RS232 drivers will use +/-12V.
I'm afraid that if i) it used to show activity, but no longer does so, and
ii) the main voltages (+5V, +12V) look good, something on the CPU card has
failed. But it will take a bit of digging to i) verify that, and ii) identify
the fault.
> The only signal that I can identify that seems likely to have this kind
> of effect is LTC, but I don't know enough about LTC to know if its
> absence could cause the CPU board not to work at all, although I see
> above that you think it unlikely.
I have yet to trace how the LTC signal is used in the KDF11-U, but on the
KDF11-A, it not being there is a total NOP. (In fact, in the BA11-N/S type
mounting boxes, there's a 'Clock Enable' switch on the front panel which turns
the LTC signal off - and the machine runs fine with it off - except for the
TOD clock not ticking.) That clock signal - totally different from the main
CPU clock - is only used as an input to what is in effect a peripheral.
> I had a console attached. There is nothing on the console. When I first
> got the machine I did get output on the console.
Not a good sign, alas.
If you have a scope of some kind, and want to keep poking, I'd recommend that
you start by seeing if the clock is running, and move forward from there. The
KDF11-U prints are online, as is the KDF11-U Tech Manual. Skim the chapter on
the CPU (4, I think), and then grovel around in the prints for a bit. Don't
try to totally understand it all, just skim through it, so you know roughly
where most things are.
Noel
On 3/28/22 21:55, Jon Elson wrote:
> On 3/28/22 17:22, Rob Jarratt via cctalk wrote:
>> Its 600mV, but it is more of a spike than a ripple.
>>
> That's probably not real.? It looks like noise pickup from
> the probe ground lead.? Try disconnecting the probe tip
> and see if you still get similar signals.? I have seen
> similar noise lots of times when measuring things with
> switching power supplies.? The high frequency content is
> pretty unlikely to be actually there on the power rails,
> with a bunch of decoupling caps all over the boards.
>
> Jon
>
Without getting political I was saddened to hear of the destruction of the
Club 8-Bit museum in Mariupol, Ukraine. One can only hope that D.
Cherepanov can rebuild his museum someday keeping classic computing in that
part of the world alive.
Murray--
Hi,
Digital
Networks & Communications Buyer's Guide
1987 April-June
Also some DEC Letterprinter 210 and LA50 Printer manuals, ask for a list.
For postage from Toronto Canada.
--Toby
Ethernet invented in 1973-74 at Xerox PARC in Palo Alto, CA, evolved over
many years.
This April 13th Webinar will trace the history and development of Ethernet
as a 10 Mb/s product up through the release of the DIX (DEC-Intel-Xerox)
spec in 1980. This was the starting point for the ongoing IEEE 802.3
Standard activities. Speakers include Gorden Bell, Dave Liddle, Bob Metcalfe
and seven other pioneers who were there for the transition.
More detail at <https://r6.ieee.org/sv-techhistory/?p=1030> SVTHC website
Register
<https://www.eventbrite.com/e/ethernets-emergence-from-xerox-parc-1975-1980-
tickets-301085664327>
Tom
Hi All
????? I did find some RX50 images of the MicroRSX distribution.
???? So I fired up my DEC Celebris FX. It runs W95 and has a 3.5 inch
floppy, a real RX33 5.25 inch drive and a CD-R.
?? Its accessible on my network so getting files onto it is not a problem.
??? So install putR.com , and transfer the image files.
? ? Huh! putR says the RX50 disk is write protected. Its not and the
drive works normally with the disk from the MS DOS prompt.
? ?? So much for putR writes RX50's on RX33!
??? Rod
A friend who used to work as a software trainer for DEC sent me the following link (https://m.youtube.com/watch?v=uIqlMfSCs0E), which points to an hour-and-a-half-long YouTube video from June 2021 about the history of DEC. It is a Zoom presentation from the Maynard Public Library done by a local newspaperman. It is fairly general, but was attended by a number of former employees, some of whom made comments.
Here's one for the memory banks. I have a number of TRS-80's.
Back when they first came out I bought a couple of the FreHD
Hard Disk Emulators made by Fred Vecoven. They worked great
and made life a lot easier. Then, I had reason to put everything
away for a long rest. I just pulled them out and set them up
again. Neither of them does anything. As a matter of fact, in
my 4P they even keep the system from booting from floppies.
Anybody else run into something like this? Is there something
that would go dead if they sat idle for several years? I checked
the CR2032 batteries and they are still alive so it's not like
they ran out of power or anything. Any hints?
bill
Looking for a couple of MAN-3A (single character, seven-segment red LED
display) to restore a '70's pocket calculator.
One digit is missing a segment. I had another 3A in my LED drawer - and
IT has a different bad segment... aargh.
No luck searching the usual places online.
Can anyone help?
thanks.
> From: Steven Malikoff
> I have finally got around to scanning the print set for the DEC ME11-L
> memory expansion unit
Ah, thanks for that. The prints for the boards are available, in the
PDP-11/05 Engineering Drawings (on pp. 115-137), but the MF11-L backplane was
previously missing. (The -11/05 generally mounts MM11-L sets in the main CPU
backplane, so the MF11-L backplane is not included in the -11/05 prints.) It
is the non-parity MF11-L backplane (DEC part number 54-09959), not the parity
one (part number 54-10331), though. (My theory is that the non-parity version
can be upgraded to parity with an etch cut, and some added wires, FWIW.)
Noel
I have finally got around to scanning the print set for the DEC ME11-L memory expansion unit
and you can find it at
https://archive.org/details/dec-me-11-l-core-memory-system-engineering-draw…
The quality is acceptable given that the office supplies shop where I (DIY) scanned them on an A3
scanner only allowed output as JPEG or PDF (undoubtedly wrapped as JPEGs inside) so I thought there
was no point degrading any more than necessary with editing the JPEGs to another format just to
re-save them. I just bundled the raw scanned pages as-is and it looks fine.
There's also some miscellaneous fragments for the M7050, M715 and M840 module drawings which came
with the ME11 set.
Steve.
I cannot find a datasheet by any of the numbers silkscreened on these ICs.
Could these be proprietary IBM P/N numbers?
https://www.dropbox.com/s/f6rvemx9ldbbv5x/EPROMS1.jpg?dl=0
No need for a Dropbox account, close the login pop up and you can view the
image.
Thanks
Don Resor
I came across a reference to a cctalk message from 9 September 2006 and
would like to read the rest of the thread with the subject "PDP-8m Console
Switch Problems - fixed!".
Unfortunately it appears that the cctalk archive does not go back to 2006.
Is there some place with the complete cctalk archive or at least back to
Sept 2006?
I have also been trying to search the cctalk archive, but short of
downloading every month and unzip it, there appears to be no easy way of
searching. What do experienced cctalk members do?
Thanks
Tom Hunter
In case anyone else has been looking some of these, there is a listing for
multiple tubes-of-11 on eBay at a moderate price:
https://www.ebay.com/itm/123710245814
QTY-11 PCS. AMI SEMICONDUCTOR DC319 C04090 Integrated Circuit - (UIC
40378901)
It's documented in the DEC Semiconductor Data Book, Volume 1 (1987), pages
3-27 through 3-41:
http://bitsavers.org/pdf/dec/semiconductor/
-----
Those look like "stripline" RF/microwave packages. PCBs will have cutouts
for the package body, so that the leads can be soldered flat (no bends)
directly onto impedance-controlled leads on the board.
On Tue, Mar 22, 2022 at 6:17 PM Oldcompu via cctech <cctech at classiccmp.org>
wrote:
> Anybody know what these are? Maybe RF related? Found on a box of computer
> ships.
>
> https://share.icloud.com/photos/0294pRVHPFQMShUZic2vFvneg
>
>
>
NEW CONTRIBUTION TO US "CALL-A-COMPUTER"? PILLSBURY? TIMESHARE...? ?WHAT? SYSTEM WAS? THIS? RUN ON ?? ? ?IT IS A? BIG 3 INCH 3 RING AS NEW TIMESHARE MANUAL.? THANKS? ED#? ? SMECC MUSEUM
This is the CPU board out of a first generation 1982-83 IBM Electronic 85 Typewriter (Electronics Driven Selectric).
I was looking to archive the software/firmware from these. The machine was exposed to some dampness. Corrosion has ensued on the interface connector between the CPU and driver boards.
The next year, more energy efficient memory ICs were used. Memory power failure back up only consisted of 3 AA batteries and could last up to one year. The predecessor (this board) required 6 AA size Nicads and would only retain memory for a few hours.
IBM using their apparently very large stock of OLD aluminum covered ICs in as many products possible I guess.
Don Resor
-----Original Message-----
From: wrcooke at wrcooke.net <wrcooke at wrcooke.net>
Sent: Sunday, March 20, 2022 7:13 PM
To: D. Resor <organlists1 at sonic.net>
Subject: Re: ID UV erasable PROMS used on an IBM PC board?
> On 03/20/2022 8:59 PM D. Resor via cctalk <cctalk at classiccmp.org> wrote:
>
>
> I cannot find a datasheet by any of the numbers silkscreened on these ICs.
>
> Could these be proprietary IBM P/N numbers?
>
> https://www.dropbox.com/s/f6rvemx9ldbbv5x/EPROMS1.jpg?dl=0
>
> No need for a Dropbox account, close the login pop up and you can view
> the image.
>
> Thanks
>
> Don Resor
More details would help. What is the board? Do you know at what address in the PC memory map they fit?
Based on the info you gave and the picture I would bet $1 they are standard 2764 chips. The 2764 was the first standard chip to have 28 pins. The size of the die visible through the quartz window is consistent with 2764 (as opposed to 27128 or 27256) and the fact there is room for 3 which would give 24K total. The PC didn't have a lot of places in the memory map that would allow more than 24K. Three 27128s would be 48K (a LOT in those days) and the 27256 would be 96K.
I can't help with the part numbers. But I doubt they are IBM proprietary. The vast majority of chips used in the early PC line were standard from other companies.
Will
I cannot find a datasheet by any of the numbers silkscreened on these ICs.
Could these be proprietary IBM P/N numbers?
https://www.dropbox.com/s/f6rvemx9ldbbv5x/EPROMS1.jpg?dl=0
No need for a Dropbox account, close the login pop up and you can view the
image.
Thanks
Don Resor
I found my old Model 745 in storage and other than needing a print head clean
and adjusting the printer contrast, it works splendidly. It has the manual and
I've got some plugs to build it an RS-232 connector when I find some more round
tuits.
This whetted my appetite for other 700s, including the (in)famous bubble memory
763/765. I was able to land a set of 765 ASRs. One of them came with Telenet
transcripts from The Source (various logins from 1978 to 1980), which was
really cool reading. I'll scan these.
However, neither of them work. Both power on, but they immediately go into
COMMAND mode and sit there, which appears to be abnormal behaviour based on
what I'm reading in the service manual (thanks, Bitsavers!). The NUM LOCK
switch works and the paper advance works, but nothing else appears to elicit a
response. One of them advances the page and acts like it's printing the command
prompt, but the other one doesn't even do that.
The service manual suggests I need to replace both the TMS 9980 and 8080
boards, which would really suck. I'm hopeful that the one that's "more active"
has a working 9980 board and I can use the 8080 board from the other one. (I
haven't even gotten to the bubble memory yet.) Anyone repaired these units or
have an idea of a repair strategy other than replace damn near everything?
TELENET
303 8A
TERMINAL=
@C 301 24
301 24 CONNECTED
DIALCOM NETWORK SYSTEM 10
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Simplicity is the ultimate sophistication. -- da Vinci ---------------------
>> 301 24 CONNECTED
>> DIALCOM NETWORK SYSTEM 10
>>
> Please do scan these! It is hard as hell getting info on The Source
> and also on Dialcom!
Yes, I definitely plan to transcribe them. There is potentially some
copyrighted material here but I think I can just excerpt that and still include
all the rest of the login process, etc.
Still, would be nice to get the terminal itself working and see what's in the
ASR's bubble memory, assuming that's still operational, so any ideas people
have would be appreciated.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- mouse, n: A device for pointing at the xterm in which you want to type. ----
I missed a lot of this because g-mail decided to bounce some e-mails.
I would like to make a couple of observations:-
1. Many real accredited museums have a smaller percentage of their artifacts
on display than private collectors. In the UK both TNMOC and the Science
Museum Group have large quantities of hardware that is not displayed.
The science museum usually catalogues it but it is not really helpful if you
can't see it.
2. All the private collectors I know are very happy to show and demonstrate
what they have. It might not be catalogued so well but generally they want
to show it off....
Dave
G4UGM
(Now feeling guilty because what I have is neither catalogued or on display)
Does anyone have or know whether the schematics for the IBM 5110 or 5100 are available?
And the tightly related question of whether anyone has done ROM (ROS) dumps?
There are some service manuals on bitsavers, they are field-service board-level manuals, mostly step-by-step problem resolution guides, no schematics.
As a system, it's small enough to be reverse-engineered, in that regard it's tractable. However, it's implemented using IBM's mid-70s PCB and IC technology, increasing an RE effort by a couple orders of magnitude if not approaching impossible, unless one were to develop some robotic probing system and software.
There was a 5110 on ebay, non-working, that a friend had some interest in. It was quite a gamble at the price, in the absence of real tech info. ... Apparently it's been delisted, so my question is just curiousity at this point.
Hi all,
Does anyone happen to have a copy of these squirrelled away?
- Oregon Pascal M68000 -- cross compiler for VAX (or any other host
platform). Probably called "P68.EXE" or something similar.
- Oregon / Taumetric M68000 Cross Assembler for VAX (or any other).
Probably called "MASM.EXE" or similar.
- Oregon / Taumetric M68000 Linker for VAX (or any other). Probably
called "MIL.EXE" or similar.
The assembler and linker might be ports of Motorola's M68KMASM and
M68KLINK -- so something equivalent which takes the Motorola-format .SA
files and spits out .RO files should work instead.
I've been tasked with getting some ancient code building again, and as
usually happens, the "backup" is incomplete...
Thanks,
--
Phil.
philpem at philpem.me.uk
https://www.philpem.me.uk/
I was visiting a new thrift store and saw a disk pack they had. I joked
that mine are just fun display/conversation pieces.
Do the giant drives suffer the same head crash issues that a bad zip disk
can do or are these safe if someone actually wanted to see what was on them?
At 08:25 PM 3/16/2022, John Herron via cctalk wrote:
>I was visiting a new thrift store and saw a disk pack they had. I joked
>that mine are just fun display/conversation pieces.
Wait.... you bought it, right? Was it $2?
- John
Exhibitors wanted! Deadline to apply is April 1. Exhibits are NOT limited to
the shows two main themes.
"Ever wonder about the roots of today?s technological society? Did you
spend Covid nostalgically playing old video games from the past on an emulator?
Do you want to get hands-on with computers ranging from the 1960s thru the
early 1990s?
Come to the Vintage Computer Festival East in Wall, NJ on April 22nd thru
April 24th, 2022.
On Friday, April 22nd, there are classes in everything from programming the
Apple II computer to "learn to solder" sessions for both kids and adults. You
can even solder together your own Intel based computer with our partner
GlitchWorks.
On Saturday and Sunday (April 23rd & 24th), join us for hands-on exhibits of
vintage and classic computers along with talks from the people who were at the
beginning of vintage computer history. Learn how vintage computers lead to
today's world of technology becoming commonplace instead of niche hobby.
This year we have two themes for our weekend talks: Women in computing and
Computers for the Masses.
Talks include a reunion of Commodore employees talking about their days
working at Commodore Computers as well as the creators of the Commodore Vic-20
and C64. Talks by Margaret Morabito, the editor of RUN magazine. Learn the
history of video game programming starting with the Atari 2600 to modern times
with Burger Becky a long-time veteran of the video game industry.
Consignment sales will be open all weekend where our members will be selling
everything from vintage Apple to Zenith computers and everything in between, as
well as parts for computers, peripherals, and other vintage computer equipment.
Who knows, you may find the items to complete your nostalgic journey back to
the 1980s. Will you find the personal and home computer that you have been
looking for?
Learn more about the Vintage Computer Festival East at
https://vcfed.org/wp/events/vintage-computer-festival-east"
I have here in my hands a DEC H222A (16Kx18), part of a MM11-DP, that took a
blow at sometime in the past. In consequence there are a number of small
parts damaged (snapped diode, crushed axial electrolytic, chipped mica
capacitor, cracked/broken SIP resister net) but those all appear to be
relatively easy to replace.
What's not so easy to replace is the MC75325L Dual Memory Driver (L =
Ceramic) that was de-lidded in the process :-<.
I am wondering whether anyone has one of these ICs in their spare parts
drawer that I could acquire?
I do see a MC75325P (plastic) on eBay at littlediode_components for ~20USD,
plus a surprisingly modest shipping charge (Royal Mail International).
UTSOURCE claims to have a supplier of the ceramic part "new", with a
significantly higher shipping charge.
Before I go with the ceramic part (IMO not the sort of packaging that gets .
remarked) I thought that I would check here for alternative sources.
Thank you,
paul
This is a long shot but would anyone have an interface card for a HP
9000 712 HP-UX workstation. The part number is A2263-66536 and its a LAN
card.. If anyone has one that they want to sell, let me know.
Thanks
Jesse
Cypress Technology Inc
jesse(at)Cypress-Tech.com
Saw a note on the GCC list that I thought some here might find interesting: it announces the existence (not quite done but getting there) of a COBOL language front end for GCC. Interesting. For those who deal in legacy COBOL applications that want a more modern platform, I wonder if this might be a good way to get there. Run old COBOL dusty decks on Linux, yeah...
I wonder if I can make build that front end with the pdp11 back-end. :-)
paul
Hi
????? I've just done an inventory and I have the following stock
?????? PDP-8/e Type A? Qty 4
??????? PDP-8/e Type? B Qty 5
??????? PDP-8/f?????????????? Qty 4
???????? PDP-8/i?????????????? Qty 8
???????? New production may not be for a while.
Rod Smallwood
Hi,
I also have an H500 waiting for restoration.
Maybe anyone can give better winfos about the plugs/connectors of the
patch cables.
I didn't have any, I have to make new.
With best regards
Gerhard
Zitat von cctalk-request at classiccmp.org:
> Send cctalk mailing list submissions to
> ? ? ? ? cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> ? ? ? ? http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> ? ? ? ? cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> ? ? ? ? cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more
> specificthan "Re: Contents of cctalk digest..."
I have some disks that look like they're from a DECmate II computer,
standard RX50K drives. The disk images all look like they're a mix of
12-bit (OS/78 or OS/278?) and 8-bit all on the same media. I can't
convince PUTR to make sense of the images, so I'm wondering if there is
anything else out there that is likely to be able to examine the disk
contents? I'm really looking for PUTR-like functionality to list and copy
files.
Maybe SIMH could be configured to be a DECmate II and be fed the disks?
I have a couple of disk images available in case anyone wants to try them
out - they're purported to be "DECmate II CP/M 2.2 version 2.0" and "System
Disk ver. 2.0 8/24/87":
https://drive.google.com/drive/folders/1PD0TlUPiT7MIPEX6abEn33e7s3kSXp_H?us…
- David
Found an interesting item for bid on GSA auction site if anyone interested.
Reminds me of General Data equipment...
EQUIPMENT RACKS
|
|
| |
EQUIPMENT RACKS
One lot consisting of: 2 Equipment Racks with the following built in: recorder, processors, disk drive units,...
|
|
|
Stan Irwin
Dear Classic Computers Members,I am looking for someone who had an operating floppy disk drive that can read old 5-1/4" floppy disks from the 1980s.I may also need someone to read hard, 3" floppies.?The disks can be mailed and the info can be saved as text and sent via email or to the Cloud.I would need a price estimate, as well. I live in Virginia.Thank you in advance.Terry Joseph
As there is no real cctalk traffic other than test messages I thought I
post something a bit more interesting. Here is a short video of my fully
restored DEC H500 Computer Lab with an 8-bit counter implementation
including reset:
https://www.youtube.com/watch?v=57xU3Xqnqx4
Enjoy
Tom Hunter
P.S. Is there some problem with the mailing list? The few "non-test"
messages I get are often out of context.
SYSTEM DOCUMENTATION
FOR ALUMINUM COMPANY OF AMERICA WARRICK WORKS
DATANET -30 REALTIME DATA ACCUMULATOR AND DISTRIBUTOR ... AUG 7 1964
Sent from the all new AOL app for Android
I have the mechanism for a Digitronics P135-20 Paper Tape Punch.
It turns out that Surplus Sales currently has one of these for sale; see
item "(EQP) P135-20/35".
It is accompanied by a three-page snippet of a much longer manual for this
punch.
See: https://www.surplussales.com/equipment/pdf/eqp-p135-20-35.pdf
That's the only documentation that I've been able to find :-{.
I'd very much like to find/acquire the remainder of this manual, or other
relevant documentation. Can anyone help me?
Thank you,
paul
Is there a way to do this? Or perhaps a driver in RT-11 that I could point
to an entire drive? If not, maybe I could write one with some community
guidance?
Would be a splendid way to write real media, or in my case, read the
hundreds of 8" floppies I have sitting on the shelf here for archive.
thx
jake
> and tried looping back pin 2 to pin 3
>on each serial + modem port and typing some characters, but nothing shows
>up in vterm.
? PDT-11/150 terminal and printer ports ports all require a high on pin
20, DTR, before they can send characters.? I've never used the modem
port on my PDT's but I suspect it requires the typical, pins 6, 8, and
20 wired together. Maybe you need to pull some of these pins high to
loop around?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
Spotted on ebay -
No involvement in the sale - just tagging in case any one on the list has interest.
"Muldivo Digiputer 1968 - Imperial Dialog: IBM Model B"
https://www.ebay.co.uk/itm/203849003806
On Tuesday (03/01/2022 at 04:36PM -0800), Marc Howard via cctech wrote:
> I've got a PDP 11/34 I've never opened up. It's mounted in a H9642
> cabinet. I can't get the bloody thing to extend on the chassis track
> slides.
>
> Is there a catch or lock screw on this unit?
Mine (and we may be learning, is not be a proper configuration) does not
have any release or catch to allow the CPU to slide out. I just grab it
and start pulling and it slides out-- although it does not slide easily.
That could be due to old, stiffened lubricant on the slides.
BUT! make sure you pull out the front foot at the bottom of the rack to keep
the whole rack from tipping forward if you do get the CPU to slide out.
The CPU is a heavy beast and the rack WILL tip forward once the CPU is
out far enough.
Chris
--
Chris Elmquist
If it's mounted in a standard BA11-K, no. You should be able to pull it out partially (sufficient to tip up if you have rotating slides) and then there should be locking-buttons on the slides to prevent further extension accidentally. Depressing those buttons will allow you to completely remove the chassis and its attached inner slides; the outer slides will remain in the rack. Be careful with full extraction -- the power supply is heavy and the chassis is unbalanced. It's really a two-person operation, or one best accomplished with some sort of supporting mechanism (even wooden cribbing if you are so inclined).
If it's anomalously mounted in a BA11-A (like the 11/44) then there is a finger-tab accessible through the front grill on the upper-right that pulls back a spring-loaded side-tab that engages the rack frame to prevent *any* extension whatsoever. Pull that away from the rack-frame and then pull out the chassis.
Of course, it's possible that you simply have rusted slides that are binding, in which case you will simply have to use force. Recommend _pushing_ from the rear if "reasonable yanking" from the front isn't working. Although I've encountered a fair share of rusty slides, all have yielded (slowly) to repeated yanking/pushing, even if only a few centimeters at a time. Penetrating oil applied from the sides will help, but after cleaning and polishing the slides suggest that you use graphite or lithium grease to re-lub when reassembling. Others may have alternative lubrication recommendations.
-----Original Message-----
From: cctech <cctech-bounces at classiccmp.org> On Behalf Of Marc Howard via cctech
Sent: Tuesday, March 1, 2022 7:37 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: While on the subject of cabinets...
I've got a PDP 11/34 I've never opened up. It's mounted in a H9642 cabinet. I can't get the bloody thing to extend on the chassis track slides.
Is there a catch or lock screw on this unit?
Thanks,
Marc Howard
I am wondering if I have racked my 11/24 correctly.
As you can see here:
https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ I have put the
CPU at the top and the two RL02 drives underneath.
The problem is that the CPU enclosure catches on the RL02 underneath. There
is a bit of play in the mounting bracket:
https://rjarratt.files.wordpress.com/2022/02/cpu-mounting-bracket.jpg. With
a bit of manipulation I can get the CPU to slide in. However, I am wondering
if I have racked it correctly? I don't think there is room to move the RL02s
down and it would presumably leave a bit of a gap below the CPU. There seems
to be very little clearance between the CPU and the RL02 at the front but
more at the back, but I am sure that the rails are mounted horizontally. Is
it just a matter of tightening the big screws that hold the mounting
brackets to stop the play? If so I am not sure I have a big enough
screwdriver!
Regards
Rob
Hi!
Anyone remember how to use this program that announces itself as "PDT-11
Virtual Terminal Monitor v1.07" ? I found it on a floppy of RT-11 v4.0
with my pile of PDT-11 treasures (which amazingly still seem to read fine
and work wonderfully; disk file timestamps around 1979 - 1982).
I thought maybe it was a term program, since these PDTs were kind of
famous for that sort of deployment, and tried looping back pin 2 to pin 3
on each serial + modem port and typing some characters, but nothing shows
up in vterm. It does come out of some mode into a command mode, I think,
when I send a break to the console. ^C kills it from there and I can get
back to RT.
I found online a DECUS program of the same name (vterm), submitted by DEC
circa 1979, and am wondering if this is the same beastie I've discovered on
my 8" floppy:
https://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/…
; however, when I try to click through that decus website, the actual
packages themselves seem to have been lost! Does anyone know where to
obtain the actual files that came with this 110417 from DECUS? And if I'm
on the right track, here? It would be cool to have this PDT-11 functioning
as God intended if this vterm is actually a terminal emulator type of
thing...
thx
jake
Does anyone have anything on the jumper settings for this drive?
I would like to jumper it so it can read DEC RX01/RX02 floppies.
I am looking at being able to read disks on a non-DEC systems
but I would also like to be able to use it on my Andromeda card
in a real PDP-11.
bill
Hi
????? Is the correct setting:
?????? 1. DS1 on the RD31 and the RX50's move up to DU1 and DU2.
?????? 2. DS3 on the RD31 and the RX50's are DU0 and DU1
I've tried both and it still? tries to access the RD31 and the RX50 at
the same time.
Its on a standrd BA23
R
>> (I have yet to check and see if the KY11-LB asserts SACK if the CPU
>> halts on its own accord - probably 'yes', but that's a project for tomorrow.)
Yes, it does. I toggled in the following program:
5000
5200
776
0
(what, you all can't program a PDP-11 in octal? :-) and hit 'start' and the
SACK light on the UA11 flashed out and came back on when the machine finally
halted.
So then I looked at CPU tech manual for the KD11-E, and the HALT instruction
seems to act exactly like the console has requested a processor halt; it just
sets the HLT RQST signal (see Section 4.5.5 "Operate Instructions").
So, either (console halt, or a HALT instruction) will cause the identical
response in the processor; see Section 4.10.3 "Halt Grant Requests": the CPU
sends HLT GRANT to the console, which returns SACK. As long as SACK is
asserted, the processor waits with its clock inhibited:
"The user can maintain the processor in this inactive state (Halted)
indefinitely. When the HALT switch is released, the user's console releases
BUS SACK L, and the processor continues operation"
This text is obviously for the KY11-LA; the KY11-LB will operate identically:
when the console releases SACK, the processor resumes operation.
> From: Fritz Mueller
>> when I powered the machine on, it turned out that something was
>> asserting SACK when the machine was halted
> That is quite interesting, and not what I would have expected!
Yes, I was quite surprised; I didn't expect that either. Now that I know that
the KY11-LB uses it to talk to the KD11, I can work around it, though.
I'll have to write all this up to warn others about it.
>> The thing that's puzzling me is that the M8264 seems to exactly
>> replicate the functionality of the M9302, with an 'unused' bus grant
>> being turned into a SACK. So I don't understand the point of the M8264.
> I think the only difference would be that since the M8264 is timer
> based, it doesn't need the intact end-to-end path required for
> turnaround. So your bus won't lock even if you have a broken grant
> chain or a poorly behaved or hung device eating grants.
You are right about it being timer-based, but I'm not sure the conclusion
follows, at least exactly as stated.
If there's a broken grant chain, then as you originally pointed out, the M9302
will jam SACK on. The M8264 could not even be there, and nothing would be any
different. Same thing if the CPU asserts a grant in response to a now-removed
interrupt request: the M9302 will jam SACK on, etc, etc.
I'm racking my brain to think up _any_ circumstance in which the M8264 will
assert SACK. in which the M9302 wouldn't. Thinking it through, there has to
be a grant, but it can't get to the M9302 (because otherwise it would do its
thing), but that failure to get there can't be simply a broken grant chain
(ditto). So some device has to be malfunctioning: not passing a grant along,
but eating it. So either a hard-failed component in the grant-passing
circuit, or some design flaw. (It can't be a glitch; it has to be a permanent
thing which prevents passing the grant.)
I suppose that's possible, but I can't see any othey way.
Noel
First, a minor correction:
> the M8264 Sack Timeout module ... there's next to nothing in print
> about them
There is also some coverage in EK-KD11E-TM-001, at: Section 4.7.2.4 "M8264
NO-SACK Timeout Module" (pg. 4-41, pg. 87 of the PDF), which I found while
looking for parity stuff (below).
> From: Fritz Mueller
> The KD11-E is pretty bare boned... Parity handling was also a quad "add on".
??? The KD11-E/EA doesn't do much with parity (below), so at first I thought
that maybe you were thinking of the M7850 Parity Controller (which is
actually a memory option, not KD11-E/EA specific; more below), but that's a
dual card.
The KD11-E/EA does not (like most PDP-11's) calculate parity; PDP-11 memory
units do all the work, and signal 'parity error detected' to the CPU over the
UNIBUS (using the PB line); the CPU will trap when it sees that (if enabled;
the KD11-E and -EA can disable recognition of parity errors, with jumpers).
See Section 4.7.2.7, "Parity Errors", in EK-KD11E-TM-001 (at pg. 4-45, pg. 91
of the PDF); the circuit diagram is on page K2-1 of the KD11-E/EA FMPS.
The M7850 has to be in the same backplane as the memory, but that can be a
different backplane from the one holding the CPU. So it can be 15' away, at
the other end of a UNIBUS cable.
Anyway, can you say more about the parity add-on?
>> So if i) a device requests a grant, and then drops the request at
>> _just_ the right time ... and ii) there's a break in that grant line
>> ... before it gets to the M9302, which can turn it around as a SACK ,
>> then ... the KD11-E CPU will hang!
> I believe a broken grant chain with an M9302 in place on the far side
> results in the grant being pulled up at the M9302, and then continuous
> assertion of SACK, hanging the processor straight out the gate.
Oh, right you are! (I'm glad _your_ brain is runed on - unlike mine! :-)
I happen to have an -11/04 (the -11/34's sibling) on the bench in my work
room, with one of Guy's very useful UA11's plugged into it. (BTW, the UA11:
http://www.shiresoft.com/products/ua11/Unibus%20Analyzer.html
is fantastically useful as a UNIBUS debugging tool. Everyone working on
UNIBUS machines should have one.) So I thought I'd go try an experiment.
It turned out to be a bit more complicated than I thought, but you're
basically right: a break in the grant lines (e.g. missing grant continuity
card) causes the downstream card to 'see' 'phantom' incoming grants (open TTL
inputs float high), and signal a grant on from there; and if there's an M9302
at the end of the bus, it will see that and jam SACK on.
The complication was that when I powered the machine on, it turned out that
something was asserting SACK when the machine was halted; if I put it into a
'BR .' loop, that goes away. I looked, and the KD11-D doesn't even _have_ a
SACK driver! So I tried un-plugging the KY11-LB, and the 'SACK on halt' went
away. (That machine has core, and I set the power-on vector to halt the
machine.)
Looking at the KY11-LB manual, it does in fact assert SACK (after it has sent
the KD11 a 'halt request, and receives a 'halt acknowledge'), to recognize
the CPU's acknowledgement of the halt request. (I have yet to check and see if
the KY11-LB asserts SACK if the CPU halts on its own accord - probably 'yes',
but that's a project for tomorrow.)
The thing that's puzzling me is that the M8264 seems to exactly replicate the
functionality of the M9302, with an 'unused' bus grant being turned into a
SACK. So I don't understand the point of the M8264. Whether the cause of the
grant is a rare timing window of a bus request being cancelled, or a broken
grant line; with an M9302 in the system, a SACK will result.
The only difference between the two is that because of the way grant lines
are wired, the M8264 will not respond to a broken grant line 'downstream' of
the M8264.
The M8264 does add this capability to a system using an M930 terminator - but
just switching to an M902 would be simpler. And the M9302 pre-dates the
M8264, as we can see from EK-11034-OP-PRE2. So I'm really quite confused as
to what the point of the M8264 was.
Noel
> From: Mattis Lind
> What about the M9300 board? Do you have an idea what the purpose is of
> that card?
Yes, that one's well-documented and understood.
It's intended for use on the 'B' UNIBUS of the RH11-AB, in deployment
configuratons where that UNIBUS is in use, but there's no CPU on it to
respond to NPR bus requests.
(See: http://www.bitsavers.org/pdf/dec/unibus/RH11_Peripheral_Controller_Course.p…
pg. 11 for an example; the 'B' UNIBUS of the -11/45 is used for a separate
path into the 45's dual-port FASTBUS memory.)
On such a UNIBUS, the M9300 is used at the start of the bus, and is jumpered to
allow on-board circuitry to respond to an NPR with an NPG.It also has a SACK
timeout capability, documented in:
http://www.bitsavers.org/pdf/dec/unibus/RH11-AB_OptionDescr.pdf
on pp. 69-70, but I'm not fully familiar with that.
Noel
>> On Feb 19, 2022, at 10:51 AM, Noel Chiappa wrote:
>> The -11/34 (not the /34A) has something unusual for grant timeouts,
>> but I forget the details. I'll look it up.
And here it is...
> From: Fritz Mueller
> I think you are thinking of the M9302, Noel: a far-side terminator card
> with integrated SACK turnaround?
No; the M8264 Sack Timeout module. What's an M8264, you say? Well, there's
next to nothing in print about them, but I think I've managed to assemble
enough distant clues to work out their story.
Start with EK-11034-OP-PRE2 (I have a hard-copy of it); it gives a clue as to
how it all started. In 3.10.2, "End-of-Bus Terminator", it says:
"As a result of this [SACK turnaround] circuitry [on the M9302], the SACK
timeout feature found on other processors is not required"
So if i) a device requests a grant, and then drops the request at _just_ the
right time (so a grant gets sent out when there's no device waiting to grab
it), and ii) there's a break in that grant line (maybe a missing grant
continuity card) before it gets to the M9302, which can turn it around as a
SACK , then ... the KD11-E CPU will hang!
The M8264 was apparently the first attempt to deal with this.
Like I said, there's next to nothing in print about them. EK-11034-UG-001, in
Section 1.2, "System Description", does list "M8264 SACK Timeout module
(11/34 only)" in the list of components - but says nothing else _at all_
about it!
There is one page of circuit diagram of it, in:
http://www.bitsavers.org/pdf/dec/pdp11/1134/MP00082_1134_Vol2_Sep76.pdf
on pg. 149. The rest of the prints for it (e.g. the PCB layout) aren't there,
but I happen to have one - it's a quad board with only a few components on
it. Looking at the circuit diagram, it's mostly just a 9602 retriggerable,
resettable one shot. (There's also a synchronous 4-bit up/down counter, but
that's just there to count events, and display the count in some LEDs -
probably just to make sure it isn't happening too often.)
Since I'm not a real hardware type, I'm not absolutely certain just from
looking at the circuit diagram exactly what it does, or how, but
EK-KD1EA-MM-001 Section 4.7.2.4, "No-SACK Timeout Circuitry", shows a very
similar circuit, and says it "asserts BUS SACK ... [if the device] does not
assert SACK within 22 usec after a grant line has been enabled." Presumably
the M8264 does the same thing.
Interestingly, that circuit appears in the KD11-EA prints on pg. K2-10; the
KD11-E prints have a blank space on that page where this circuit is in the
KD11-EA prints.
Since the M9302 appears in EK-11034-OP-PRE2, with SACK turnaround, I deduce
that the M8264 was produced _after_ that came out, and post-dates the M9302,
to fix the potential CPU hang issue I described - and was later dropped when
the -11/34 switched to the KD11-EA, with that circuit built in.
I'll do a page on the CHWiki about the M8264, and include an image of one.
I figure I might use my M8264 on my -11/04, which also doesn't have SACK
timeout (on the BG lines, for sure; it looks like it might have it on the NPG
line). The M8264 doesn't tie into the CPU, it just looks at UNIBUS lines, so
it can be plugged into any UNIBUS machine (near the start of the bus, since
the grant lines it monitors are wired sequentially).
Noel
hi Steve,
? There's lots of raw material out there.? Al Kossow read hundreds of
tapes a couple years ago, and posted the images at
http://www.bitsavers.org/bits/MIT/whirlwind/X4222.2008_Whirlwind_ptp/
? Whirlwind and modern readers disagree on what order the bits come in,
but other than that, the files are perfectly usable.? We have some of
the programs running in simulation, as you've seen.
? The Whirlwind tapes in the archive are all seven-level tapes punched
on 7/8" paper.
? Let me know if there's something I can help with
/guy
Date: Tue, 22 Feb 2022 12:24:18 +1000
From:steven at malikoff.com
To: "ben"<bfranchuk at jetnet.ab.ca>, "General Discussion: On-Topic and
Off-Topic Posts"<cctalk at classiccmp.org>
Subject: Re: Seeking paper tape punch
Message-ID:
<78ae9afacbca8b3ca7e7a41c677659d0.squirrel at webmail04.register.com>
Content-Type: text/plain;charset=utf-8
Ben said
> This requires a REAL MACHINE SHOP ... none this 3d printer stuff. I
> would recommend a building a 35mm film punch and reader, as film stock
> is still easy to find compared to paper tape. Zuse used them for his
> computers in Germany on the 40's. Quality Mechanical stuff is lost high
> tech.
Consumer-grade CNC stencil cutters are fine at cutting plastic sheet and should be ok with film stock.
My ptap2dxf (latest version 1.3) will produce output to cut tapes for 8-level ASCII, 5-level Baudot, 2-level Morse (Wheatstone and
Cable Code), 7-level Whirlwind, Teletype Chadless and some customising options too.
Still some other formats to do such as Colossus etc. Thanks for the notion of making Zuse tape, will look into it.
Steve.
Hi
?? Well I have had a huge response to my request.
I am unsure as to if I have defined the problem properly.
So a few bullet points.
1. The objective is to copy RX50 disk images (*.dsk format) to genuine
DEC RX50 disks.
2. The PC I want to use is a DEC Celeibris FX ie the PC and its W95
software is as supplied by DEC.
3. It has an RX33 5.25 inch floppy drive.
4. The RX33 _*is*_ capable of? reading and writing RX50 disks.
5.? putR was supposed to be able to do this. It does not.
6.? All that is lacking is the right utility.
7. Doing this does not need any disks other than RX50's.
8. Linux in any of its myriad of forms is not the answer.
9. simH is good at what it does but of no use here
10.? Its just a W95 utility program to copy an RX50 disk image to an
RX50 disk on an RX33 drive on a DEC PC.
11. So whats it called? Does it work? given the above situation?
Rod
Hi
???? Well I now have a full set of DEC orignal MicroRSX RX50
distribution disks.
An old friend who I worked with at DEC had kept his install go bag and
there they where. Not only that they are good and do boot.
Its not over, RT-11 would be a better fit so I'm looking at that.
Rod
Hi folks,
I?ve begun some work on a VT52, and need to get the power supply board out onto my bench for some work. For those who have been in here before: is there a way to detach the HV anode lead at the board side (does the white ?cap? come off the lead connector?) Or is the only option to unclip at the CRT itself?
They don?t make it easy to get to the anode cap in this terminal ? one has to pull the whole tube, with the power supply board in tow. After doing this for an inspection, I find the anode cap looking little brittle and covered with some red, oily ?goop?? I?d rather just leave that alone and detach from the board side if it works that way?
cheers,
?FritzM.
Speaking of? tubes in computers.... 1st Honeywell 1000 computer used some surprise tubes!? ??Imagine our surprise back then as? we unpacked our? first?
group of? contributed Honeywell 1000 logic and saw....? LOCTAL TUBES!?Although SMECC does not? have? a complete Honeywell
system of? this model? (CPU and? PS would? weigh in at 25,000
pounds? we have been told)? We DO possess? a wonderful
collection? of documentation, parts? and? misc.? material
related? to it, perhaps one of the best. Who else has some?
We? used? to? think our 2 inch QUAD? videotape
was a monster reel of? tape...BUT? WAIT!The First Honeywell Computer used 3 Inch Wide Tape!
It was like mounting a Volkswagen Tire Wheel
onto your computer tape drive! Channels or tracks on the tape... 31 Channels ?ALWAYS LOOKING? FOR MORE RELATED TO THIS COMPUTER!? See more info on this computer at:
http://www.smecc.org/honeywell_datamatic_1000.htm
drop me a note at? couryhouse at aol.com?
The 11/83 question sounds like a job for SCSI2SD to me. Install a system
with simh. dd the resulting disk image to your sd card. Hook the SCSI2SD
up to your 11/83 and boot from the card. Copy the contents of that drive
to your real SCSI drive. Done.
SCSI2SD cards are not expensive and are a tremendous value for money.
> From: Christian Gauger-Cosgrove
> From the KDJ11-E module user's guide ... the solder-side of the CD
> fingers is left unpopulated, but for the +5 and ground pins.
> The only PMI compatible option then would be the KTJ11-B UNIBUS adapter.
I forget how the -11/84-94 backplane is wired (it's wierd - the QBUS CD slots
are bussed together in a group, they're not in pairs like an ordinary Q/CD
backplane - but I forget the fine details), but how does the PMI get from the
CPU to the KTJ11, then? I know on the same backplane, it supports PMI memory
cards with the KDJ11-B.
And speaking of the KDJ11-B, I just looked at one, and _it_ doesn't have any
lands on the C/D connectors, side 2, either! Probably because the PMI only uses
side 1 lands:
https://gunkies.org/wiki/Private_Memory_Interconnect#Pinout
Given that the KDJ11-E can do master-slave cycles through the KTJ11-B (to
read UNIBUS device registers), it has to be able to do master-slave cycles on
the PMI. What I don't know is whether, on a 2MB KDJ11-E, it will try and send
memory reads for locations > 2MB out the PMI, or whether all reads below the
UNIBUS address space (in 22-bit address terms) are sent to the local memory
_only_.
Someone with a 2MB KDJ11-E should try it...
Noel
At 08:24 PM 2/21/2022, Steve Malikoff via cctalk wrote:
>Consumer-grade CNC stencil cutters are fine at cutting plastic sheet and should be ok with film stock.
>My ptap2dxf (latest version 1.3) will produce output to cut tapes for ...
Meaning the Cricut kind of device? Clever! So it works for
short sections?
Has anyone ever made a Cricut style cutter that has a continuous feed
of tape?
Why did you pick AutoCAD DXF as compared to Adobe Illustrator?
At 07:02 PM 2/21/2022, Paul Koning via cctalk wrote:
>I understand there is a group called "Green keys" -- ham radio operators who use old "teletype" machines -- which in that community means wny sort of keyboard telex-type machine, not necessarily made by Teletype Co. though US ones often are. 5 bit machines are common in that crowd, some 8 bit machines also appear. I haven't participated, but I would think that you might find pointers to options there.
GreenKeys mailing list
Home: http://mailman.qth.net/mailman/listinfo/greenkeys
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:GreenKeys at mailman.qth.net
They can be very helpful. They tend to focus on other non-33 teletypes.
The list can be a good place to find out about people selling or giving
away equipment, though.
The collectors of the heavy, older, machined teletypes tend to shake
their heads at the high prices and popularity of the light-duty
cheaper punched-metal 33s.
You might find someone giving away a bulky heavy ASR 28 that
handles 5-level tape...
https://www.telegramcableco.com/teletype-model-28-asr.htmlhttps://en.wikipedia.org/wiki/Teletype_Model_28
Less common to find them giving away a 33 because the computer nuts
will pay $xxx to $x,xxx for them.
- John
> From: Bill Gunshannon
> Just wish I could get some PMI memory for that 93.
?? The KDJ11-E in the -11/93 comes with a minimum of 2MB on the CPU card.
That's enough for almost 16 maximum-sized processes (assuming they aren't
sharing program texts - almost double that, if they are). Does one really
need more than that for vintage retro use?
Besides, the on-board memory operates at full speed (same as cache memory on
the KDJ11-B); even if you added PMI memory, the KDJ11-E has no cache, so it
would be a _lot_ slower than the on-board memory.
Noel
PS: Can people _please_ trim messages they are replying to, so we don't all
have to scroll down past a bunch of irrelevant drek? Thank you.
Hi
? I have built an 11/83 in a BA23 box.
? It has a KDJ-11B, 2mB PMI memory, an RQDX3 with an RX50 attached,
Plus a CMD CQD 220A Disk controller with a digital RH18A 2Gig SCSI drive
attached.
Diag sees drive as RA82.
It boots and runs the diag disk and XXDP+ just fine.
I do not have install distributions for any of the 11/83 operating systems.
Daily driver system is a Windows 10 PC.
So how do I install an operating system?
Suggestions please.
Thanks
Rod
[apologies if this is a dup, but I didn't see it coming back in any of
the cctalk digests]
Greetings CC-Talk,
? I've been working on a low-budget project to help to introduce
students to history of computing through material we have from MIT's
1950's Whirlwind project.? The activity would have more of a hands-on
feel if we could use actual paper tape.
? A simple reader is easy enough, but a punch is a bit harder.? We
don't need anything "authentic", or fast, or high performance, just
something fairly reliable.
?? If anyone can suggest where to find such a machine, could you let me
know?? Fanuc PPR, GNT 4601/4604, and the DSI NC-2400 have been cited as
possible candidates, but I don't see anything that looks like a good
match on ebay.
? Thanks!
/guy fedorkow
> On Feb 21, 2022, at 6:07 PM, Guy Fedorkow <fedorkow at mit.edu> wrote:
>
> hi Paul,
> Yes, I should have said -- I'm looking for a machine that can punch under control of a computer.
> Whirlwind actually used seven-bit Flexowriters for reading and punching (along with a high-speed reader later on), but I think it would be even harder to find fresh seven-level tape even if a seven bit machine turned up.
> I actually have been using a BRPE on loan from another contributor to this list, but it's time to return the unit, so I've started to look for alternatives.
> I assume something like an ASR-33 would do the trick, although a machine without keyboard and printer might have fewer moving parts to go wrong. But I don't see many plausible choices on ebay.
> If anyone can suggest other sources, I'll poke around
The nice thing about an ASR33 (or other hardcopy terminal with reader/punch like a TT model 15) is that you can interface them to a computer rather easily, just hook up a UART with appropriate driver/receiver circuitry. RS232 to 20 mA (or 60mA for a Model 15) isn't totally trivial but it certainly is no big deal. And those slow machines actually have the nice benefit that it's easy for people to see the action, and to get some understanding at a gut level of how slow computers were in those days.
I understand there is a group called "Green keys" -- ham radio operators who use old "teletype" machines -- which in that community means wny sort of keyboard telex-type machine, not necessarily made by Teletype Co. though US ones often are. 5 bit machines are common in that crowd, some 8 bit machines also appear. I haven't participated, but I would think that you might find pointers to options there.
As for 7 bit tape media: I found out in the past year or so that there actually was such a thing as paper tape of width designed for 7 tracks, but a lot of "7 bit" paper tape work actually used 1 inch wide tape, i.e., what is normally considered 8 bit tape. For example, the Flexowriters on which I did my first programming at TU Eindhoven used a 7-bit code but on 8 bit tape.
paul
I heard Butler Lampson once exclaim that ECL design was in some ways easier
than TTL. If you terminated every line, you get controlled impedances with
controlled edges. This was the design philosophy for the Dorado.
So, having pulled the CRT now , I was surprised to see that the ground braids seem to be held against the aquadag by only the pressure from a couple foam blocks! In my unit these aged foams are deformed and brittle. This would seem a good thing to add to the check list for looking at these?
I wonder if this explains why many of these I encountered back in the day in university terminal rooms and such were suffering from HV ?snaps?? I had always assumed it was just dust / grime / spilled cokes? :-)
Also, after a closer look, I?m surmising the red goo around the anode cap to be dielectric grease put there on purpose, and not degradation of the cap itself.
?FritzM.
> Neither the KD11-E nor the KD11-EA has built-in termination and pull-ups
> ... I haven't yet checked, but it may be the only PDP-11 CPU of which
> that is true
Also the KD11-D of the -11/04.
Noel
So, I've made what I think is a significant discovery about the -11/34:
> 1B _is_ necessary, but can be provided anywhere on the bus; most
> UNIBUS/QBUS CPU [pullups] have it built in
I was wrong. Neither the KD11-E nor the KD11-EA has built-in termination and
pull-ups (those are both done with one set of components). I haven't yet
checked, but it may be the only PDP-11 CPU of which that is true
Without _something_ doing the latter of the above, the UNIBUS won't function
at all. (The UNIBUS signal lines mostly operate as negative-logic wired-OR;
the pull-ups float it high for '0', and any board pulls it low to send a '1'.
No pull-ups, then..)
This is almost certainly the reason that the manual calls for the use of
either an M9301 ROM or M9312 ROM (which include bus termination) at the start
of their UNIBUS, in slot 3 or 4 of the CPU's backplane.
(The M7859 of the KY11-LB doesn't have pull-ups either; so in a system with a
set of KD11-E/EA cards, and a KY11-B, and nothing else, the KY11-B won't be
able to examine UNIBUS locations - even though in a system with _just_ a
KY11-B, and one of M9301/M9302/M9312, and NO KD11-E/EA, the KY11-B _can_
do UNIBUS operations.)
A system with just an M9302, and no M9301/M9312, will _probably_ work, even
though the UNIBUS is only terminated at one end (see my previous post, about
QBUS termination on one end only); the M9302 will provide the pull-ups needed
for the UNIBUS to function (above).
I have also made a number of interesting discoveries about the SACK
turnaround; I'll put them in a reply to Fritz's message.
Noel
Hi all,
A friend of mine has just acquired an Indigo (R4k with XZ graphics option),
but of course it's the usual story and the keyboard/rodent had been lost.
In absence of the genuine items they'd still be happy with a USB converter
(at least for the time being), but it seems those are difficult to come by
at present, too.
Does anyone happen to have a surplus converter suitable for these machines,
and/or keyboard/rodent? (according to sgistuff keyboard is p/n 9500801 and
mouse p/n 9150800)
[side note: they mentioned a USB converter, but I'm pretty sure years ago
someone had implemented an adapter to PC-friendly PS/2 parts, too. I'm sure
something like would do the trick, too]
thanks,
Jules
> From: Jay Jaeger
> SACK turnaround capability so that the machine doesn't hang accessing
> an address that doesn't respond on the UNIBUS.
Umm, I think you're mixing up i) grant timeouts and ii) master-slave
timeouts.
All PDP-11 CPUs have master-slave timeout handling; after a short delay
(10usec or so) with no SSYN (UNIBUS) or BRPLY (QBUS), they resume processing,
and take an immediate trap. Most OS's (UNIX, for sure) use this when they are
sizing memory.
Grant timeouts are less well-documented. I think most CPUs deal with this (not
receiving a SACK 'fairly quickly' in response to a grant); I think they
basically just ignore t, and keep processing. (That is because there are
legitimate causes for not having a grant ackknowledged; e.g. if a device is
requesting an interrupt, and then just as the CPU sends out a grant, the
device is reset, the device won't respond to the grant, since it's no longer
trying to do an interrupt.)
The 'SACK turnaround' I think is only used with system health verification;
the system wants to make sure that the grant lines aren't broken anywhere.
(That's because _if_ a grant line is broken, devices downstream of the break
can no longer do interrupts, which generally _will_ hang the overall system,
when interrupts don't work as usual.) To do this, the CPU sends an
_un-requested_ grant out (on startup), and the SACK turnaround circuitry on
the terminator turns it around and sends it back to the CPU; when the CPU sees
that, it knows the grant line has no break.
It probably caused more problems than it caught, which is my guess as to why
no QBUS machine has/uses it.
The -11/34 (not the /34A) has something unusual for grant timeouts, but I
forget the details. I'll look it up.
Noel
Hi,
my computer club c-c-g.de could acquire the remains of a VAX9000 !
The machine ran at the GWDG computing center in G?ttingen, Germany,
around 1993.
Parts of it were in stock of their museum for 20+ years.
See lots of hires-pictures at
https://c-c-g.de/fachartikel/359-vax-9000-ein-starker-exot
(scroll to the bottom for a slide show).
Joerg
I have a PDP-11/24. I have never got very far with it because of power
supply problems which I am hopeful will be resolved soon. Looking at the
technical manual, it describes an M9312 bootstrap/terminator module. The
machine did not come with one of these.
I am not sure how the machine could have been useful without it. It did work
briefly before the PSU failed and I remember getting a console prompt. So,
is the M9312 essential to ever get this machine to boot up an operating
system?
Thanks
Rob
I have one of these and would like to use it, however it appears to only
partially work.? Here is what I have found that works and what doesn't:
1. CSR and DBR are present and operational.
2. Jumpers set to 'factory'.
3. D/A portion works, can deposit codes in ODT and see voltages out on
DAC pins that change depending on the octal value deposited in CSR+4 or +6.
4. A/D portion returns full scale code, either 3777 (2's compliment) or
7777 (offset binary) whether in the input is open or shorted to gnd.
I think the problem is that the A/D inputs are not exactly protected and
damage has occurred to this portion in the past.
Does anyone have any info on the A/D module?? Who made it?? Can you open
it up?? Does XXDP have a test for this?
Doug
I'm downsizing. Have to get rid of everything. The driveway is filled systems test equipment, components, parts, books, etc. Several thousand TTL chips prototyping boards. Come out and take what you. Junk Bees will be here on Tuesday for what is left.
Call 925-998-9968 for directions.
> From: Rob Jarratt
> is the M9312 essential to ever get this machine to boot up an operating
> system?
Interesting question. I don't have my -11/24 running yet, so this reply is
theoretical, not tried in practice (and as we all know, the difference
between theory and practice is even larger in practice than it is in theory),
but here goes.
The M9312 basically provides two things: 1) UNIBUS termination, and 2)
boostrap ROM.
To further subdivide the former, it provides 1A) analog termination (i.e. a
resistance at the end of a transmission line that prevents reflections of
signals passing down the otherwise un-terminated transmission lines of the
bus), 1B) pullups (so those transmission lines normally float at roughly 3V,
unless actively driven by one of the boards plugged into the bus) and 1C)
'SACK turnaround' (a start-up 'safety check' where an un-requested - and thus
'un-grabbed' by any device - bus grant from the CPU on start-up is 'turned
around' by the terminator; this verifies that the grant lines are un-broken
between the CPU and the terminator - e.g. by someone forgetting to plug in a
grant jumper).
1A is not _absolutely_ necessary; this can be seen in small QBUS systems (the
QBUS is, at the analog level, sort of identical to the UNIBUS; this an be
seen in the use of the same transceiver chips, such as 8641's, on both) which
can get away without 1A in small configurations. Whether it's needed on your
-11/24 is hard to predict, theoretically; the easiest thing is to just try
it and see. Note: it may 'work' without it, but not be as _reliable_ as with
it.
1B _is_ necessary, but can be provided anywhere on the bus; most UNIBUS/QBUS
CPUs have it built in, and so does the KDF11-U of the -11/24: see pg. of
MP01028.
1C is required by _some_ UNIBUS CPUs (ISTR that the -11/04 won't run without
it), but the KDF11's in general don't; e.g. the -11/23 definitely runs
without it. The KDF11-U might have outboard circuitry to require it, but I'm
too lazy to grovel over the prints to see. Easiest to just try it and see.
For 2, it all depends on what you're booting from. E.g. the RK11 has a simple
enough bootstrap that you can just enter it manually (although it gets old
after a while - I remember re-'programming' (think 'soldering iron' :-) a
castoff BM-792 someone gave us for our -11/40 so I wouldn't have to).
But if you're loading it over the console serial line, e.g. with PDP11GUI,
you don't need any ROM bootstrap - the built in console ODT will be enough.
You can also load a bootstrap that way; I was booting off the QSIC RK11 with
a boostrap loaded over the console serial line; that was faster than the
bootstrap in the BDV11. This requires finding - or writing - a bootstrap,
which for later DEC mass storage controllers is not trivial.
YMMV.
TLDR version - probably not!
Noel
Anyone want a KK11-A:
https://www.ebay.com/itm/275173894774
US$200 sounds like a lot, I know, but KK11-A'S and FP11-A's are going for that
much; an FP11-A just went for US$250. And KK11-A's are rare; this is he first
one in a while.
Noel
> From: Rob Jarratt
> I suspect some of the other cards that were in the machine might do the
> necessary termination stuff.
Different answers for each part of the functionality.
1A and 1C fundamentally have be at the end of the bus, physically. So,
unlikely; since _other_ cards aren't, generally, designed to go there.
1B could be anywhere, but I've basically never seen anything but a CPU or a
terminator with 1B functionality - probably in part because the same physical
components uually do both 1A and 1B. (Oddball exception: M981 UNIBUS jumper,
in the -11/40 - but that's 'sort of' part of the CPU.)
2, yes. E.g. the KT24 UNIBUS map has sockets to hold bootstrap PROMs.
(Compatible with the M9312's.) Others, too; e.g. the KTJ11-B UNIBUS adapter
(although that is not seen in an -11/24). Maybe others, but I can't recall
off the top of my head.
Noel
I am trying to test a couple of H745 regulators with a DC bench PSU and I am
having some problems with testing them.
My bench PSU is a twin unit so I can supply the +15V required as well as the
"AC" input using 20VDC from the other half of the bench PSU. The problem is
that I don't think the bench PSU can supply enough startup current to allow
the regulator to run. It can only supply 5A max.
I have seen with the H744s that if I put too big a load on them, then they
can't start because of the heavy startup current required. I can start them
with a lower load and then add load once the regulator is running without
breaching the current limit of the PSU.
With the H745s I have tried reducing the load to see if I can get them to
start, but a 10R load appears to be too much and the regulators draw the
full 5A without outputting -15V.
I have two H745s, both exhibit the same behaviour. I suppose they could both
have the same fault, but I am inclined to think that perhaps they need a
higher startup current than I can supply. Can anyone confirm this?
Thanks
Rob
Hey all!
While going through floppies I found these and was wondering what they
were. Only clue in Google was someone asking in 1997 same thing.
BL-T540B-M1 CZUFDB1 USER TESTS
BL-T541B-M1 CZXD1B1 FIELD SERVICE TESTS 1
BL-T542B-MC CZXD2B0 FIELD SERVICE TESTS 2
BL-T565B-MC CZXD3B0 FIELD SERVICE TESTS 3
BL-T583B-MC CZXD4B0 FIELD SERVICE TESTS 4
Any ideas? The first one does not have a write protect tab, the others
do. There is also one other disk I found
CZMX4E0 Micro 11 Maint RX50 4
On this one the write protect flag was torn off (was on from factory and
removed)
C
Hey all --
I've had this HP 2100S mini sitting on the bench for a bit, waiting, and I
wanted to go through the power supply and test/reform the capacitors this
past weekend. The processor service docs cover getting the supply out
(which is slightly cumbersome) and I have that step done. But neither the
processor docs nor the power supply service docs seem to cover how one
disassembles the supply itself. (Has a really thorough guide to how the
thing works though, that I'm hoping I won't actually have to use anytime
soon.)
There are a lot of parts in this unit, and I'm not seeing a method to the
madness. The capacitors are fairly easy to *get to* but actually removing
them for testing / replacement seems to be another matter entirely. Anyone
out there done this before and have any advice?
Thanks!
- Josh
Hi Ben,
>? I can't seem to find this anymore.? I have seen a few mentions that there is a "wrapper" installer that is necessary to install 7.2 on an ES47/ES80 >machine, and I'm hoping that it was archived or mirrored some place...
Back then in 2016, I also looked for these images for my ES80 machine on the HP site and tried to find ftp mirrors, but all I found were broken links. I would be happy, too, if anybody has a copy of these installation sets.
Cheers,
Pierre
*The vintage Computer Federation will be having their 3rd swap meet.*
*Saturday, February 26, 2022*
*8AM to 2PM*
*ADDRESS*:
*Indoor swap Meet*
InfoAge Science and History Museums (Camp Evans)
2201 Marconi Road,
Wall, NJ 07719
Buildings 9010-D, 9032-A, 9001
*GPS location*: Google Maps <https://goo.gl/maps/YiEnhJAtffHTnfn8A>
*Satellite Map*:
*Street Map*:
*EMAIL*: swapmeet at vcfed.org
*PHONE*: 732-722-5015
*Flyer:* 2022-VCF-Swap-Meet-Flyer
<https://vcfed.org/wp/wp-content/uploads/2022/02/VCF_Swap_Meet_2_26_2022_LQ_…>
*Website*: https://vcfed.org/wp/vcf-swap-meet/
*VENDOR COST* is per space. First space is $20, each additional space is
$10.
This time it is an *indoor* swap meet. *Bring your own table!* Table isn?t
required, but recommended.
A space is considered a 6 by 3 foot area (the general size of a table).
*Vendor setup at 7AM.*
*FREE GENERAL ADMISSION!*
*SEND PAYMENT TO*: paypal at vcfed.org (FRIENDS AND FAMILY OPTION)
Write in the note section:
[your name]
VCF Swap Meet 2/26/2022
Number of spaces:
*Click HERE for Swap Meet Vendor Signup*
<https://docs.google.com/forms/d/e/1FAIpQLSfplnIROL-TTJ3qNkIo45mTelGNY3QCaFi…>
* Reservation doesn?t guarantee sales.
* The Vintage Computer Federation is only providing a space, vendors must
bring their own tables.
* In case of inclement weather, money paid will be refunded.
* All items that you bring must be taken with you. No items are to be left
behind.
* Bathrooms on site
* Limited food and drink options available.
The same info can be found here: https://vcfed.org/wp/vcf-swap?meet
<https://vcfed.org/wp/vcf-swap-meet>
*EMAIL*: swapmeet at vcfed.org
*AFTER THE SWAP MEET, COME VISIT OUR VCF MUSEUM @ INFOAGE!*
We are open from 12PM to 5PM: https://vcfed.org/wp/vcf-museum
The Vintage Computer Federation Museum is located nearby the swap meet and
is part of InfoAge Science and History museums.
InfoAge and VCF Museums are open every Saturday, Sunday and Wednesday from
12PM to 5PM
InfoAge museums: infoage.org.
Hi guys-
Is anyone aware of an archive or mirror of HP / Compaq's Red Hat Linux 7.2 for Alpha download site:
ftp://ftp2.compaq.com/pub/linux/RedHat/7.2-alpha/release-isos/
And the update site:
ftp://ftp2.compaq.com/pub/linux/RedHat/7.2-alpha/updates/
I can't seem to find this anymore. I have seen a few mentions that there is a "wrapper" installer that is necessary to install 7.2 on an ES47/ES80 machine, and I'm hoping that it was archived or mirrored some place...
Thanks in advance!
-Ben
In debugging my DECtape interface lashup, I found that one of my head
has two open windings.? Specifically, one channel has an open 'ground'
with the other two lines apparently the full winding of the channel.?
The second channel failing has no continuity between any of the three
lines.? I have tested the other head and it has all the requisite
continuity so I'm hoping I can at least get a single spindle running.
Visual inspection of the head 'suggests' it might be caused by the
age-old 'wire stress' of being captured within a polyester resin and
then finally snapping due to internal stress.? I see lots of internal
stress cracks on this head so I'm probably toast on this one.
Are there documents on how the heads are made?? I.e. number of turns of
number X wire; cap of X micros etc.? I'm not (yet) seriously
entertaining the idea of rebuilding this head, but it looks pretty low
tech.? These heads are Western Magnetic heads without a model number
(only serial number 19976 - don't know the other head S/N as I haven't
removed it yet.) And the look to be hand made...
Has any ever attempted repair of one of these?
-Gary
I realize this a rare bird indeed, but would anyone just happen to have a
Varian 620/L backplane netlist hanging around?
Unless I missed it, the schematics on bitsavers do *not* have it.
Hey guys-
Anyone on here know much about the Marvel boxes? I've had one for years but never had much time to fiddle with it. I'm looking at the partitioning features. In particular, the manual says:
Hard partitions must be on 2P boundaries
Tru64 only supports hard partitions
However, I can confirm that you can definitely create a hard partition with a single CPU. This got me thinking, and I dug a little deeper into the MBM CLI. The manual seems to suggest that this is the case, but says that the operating system won't work correctly in that configuration. Anyone know why not?
When you create a hard partition, you specify what type of subpartition the hard partition can contain. The manual says that only "soft" partitions are officially supported, but the CLI also allows you to create subpartitions of type "firm" and "semi-firm". Does anyone know what "firm" and "semi-firm" partitions do differently than soft partitions? And does Tru64 work with any of that, or is all of that OpenVMS-specific stuff?
Also, on a side note, I don't suppose anyone here has a rail kit for an ES47 or ES80 they'd like to sell, or an I/O drawer...
Many thanks in advance!
-Ben
I have a Cisco IGS router which hasn't worked for a long time. When I was
last using it several years ago, it occasionally crashed and restarted.
This turned out to be due to a poor contact on a connection in the
cable going from the output of the power supply to the main board. I
cleaned the contact more than once but it was difficult to make it good
enough to ensure reliability.
When I switched it on more recently, it was completely dead, no LEDs, no fan
noise, no anything. I put it in the naughty pile and it sat there for a few
years before I got around to looking at it.
Today I finally managed to check it out. The ceramic F4A mains input fuse
beside the power switch on the back panel had blown. When I opened it up,
I found a POWER-ONE MAP80-4000 power supply. The main chopper transistor
labelled Q1 on the PCB is almost a dead short. It is a large plastic
packaged FET mounted on a piece of aluminium which is in turn screwed to
the case for heatsinking. Unfortunately, there are no markings on it so
I have no idea what to replace it with :-(
As Q1 is shorted across all three terminals, whatever drives it may be
damaged too :-(
After finding screw heads hidden under the label, I managed to extract
the PCB from the case and found some corrosion underneath, possibly from
leaking electrolytic capacitors :-(
There are lots of data sheets available for this power supply on the web
but they concentrate on the specifications for the unit and don't say
anything about the components :-(
There are also lots of people offering to sell power supplies like this
for way more than I am interested in spending on this project :-(
I could replace the power supply with a different one, however, I don't
have anything to hand that will fit in the approx 5-6cm headroom :-(
Anyone have any suggestions?
Regards,
Peter Coghlan.
Between the 30th of March and the 20th of April.
I am a computer collector from England and specialise on computer artefacts
>from the 1940s to the 1970s. and would love to attend one of these when
visiting my son in TN.
Many thanks,
peter vp
I've got a piece of gear here with a bad MC858P used as a bus
driver--terminated in 220/330 ohms at the far end.
Given that old DTL is a hit-or-miss proposition, I'm proposing to
substitute a 7438 OC buffer. Pinout's the same, as is Vcc.
Before I get out the soldering iron, any "don't do it" thoughts?
--Chuck
Hi,
I have 4 pcs. IDT49C402 Bit Slices, it is no problem to find a datasheet
for that chip..but it is an problem to find the pinout for the PGA84
Package. In all Datasheets that I've found only DIP68, LCC/PLCC68
PGA68 and CERQUAD68 are listet..
Has anyone a databook newer than 1989 where the PGA84 Pinout is listed?
TIA,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583
info at tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741
> From: Warner Losh
> Do those chips have ROM numbers on them?
I have updated the:
https://gunkies.org/wiki/KD11-E_CPUhttps://gunkies.org/wiki/KD11-EA_CPU
articles with the DEC part numbers for the i) microcode and ii) instruction
decode PROms.
That's not all the PROMs on the Control card - there are effing bazillions of
the damned things (I suspect they used them to reduce the amount of random
logic, so the CPU'd fit on two boards) - but it's most of them.
I have yet to triple-check them, so there might still be transcription error
or two.
> From: Rod Smallwood
> I am sure somebody will come up with the actual images either the
> original files or derived from what we have.
I wouldn't be too sure of that; silence so far. I have reached out to Mike
Douglas, to ask where the microcode dump on DeRamp came from: perhaps the
originator can help with the missing bits. (Although perhaps I should ask Al
K; BitSavers also has the dump, and it's older, so perhaps that copy came
>from the originator.)
> We have narrowed the problem down.
> Its the instruction decode ROM's that are the issue.
> The images of those are whats needed.
All of them? Or is just one failed?
I'm wondering if you've just had a single one lose a bit or two; that's
somewhat common in old PROMs. The chip you reported as failing (E111) almost
certainly couldn't have taken out an instruction decode PROM, it's nowhere
near them.
I ask because we have absolutely nothing on those PROM's contents. With the
microcode PROMs, we at least have the contents in symbolic form (see pg. 15
of MP00082; alas, we don't seem to have the KD11-EA equivalent of Table 7-15
>from EK-FP11A-TM-002), but for all the instruction decode PROMs - nada.
Absolutely nothing.
But if they're _mostly_ there, with the partial contents, and a description
of the failure mode (e.g. 'SETC doesn't set the C bit'), we might be able to
work out what bit got dropped.
Failing that, someone's going to have to volunteer to unsolder a set, and
read them out - at least, I assume that's what would have to be done. Perhaps
a logic analyzer could be attached to an instruction decode ROMwhile the CPU
ran diagnostics, and eventually a complete readout of the contents
accumulated.
Noel
>>> On Tue, Feb 8, 2022 at 6:18 PM Rod Smallwood wrote:
>>> On the M8266 CPU control board a defective 7404 (E111) has killed a
>>> bunch of the PROMs holding the microcode.
That's pretty astonishing; I've heard of PROMs dropping bits over time, but
I'm a bit amazed to hear of a failure in a TTL gate (the 74S04 is a hex
inverter; its gates are on pg. 7 of the M8266 prints - they produce uPC03-08)
taking out a bunch of other gates connected to it.
>> On Tue, Feb 8, 2022 at 7:04 PM Warner Losh <imp at bsdimp.com> wrote:
>> I found
>> https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporat…
>> which has the source code...
>>
>> But I couldn't find the tools to use these files to create microcode
>> images.
Actually, the "m8266_ucode.v.txt" there seems to actually be the program that
produced the symbolic dump (which is also available at:
http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt)
It looks like the program is in VHDL or something like that, but it doesn't
seem to have the actual microcode (was it stored/defined in another VHDL
file?); that raises the question of where the actual microcode that it was
dumping was.
It might be worth inquiring of Mike Douglas (he runs the DeRamp site) to find
out where the files in "mfe_archive" came from; perhaps the source has, or
knows of, the file which "m8266_ucode.out.txt" was a symbolic dump of - maybe
>from a complete KD11-EA simulation in VHDL?
If that's not possible,it would be trivial to extract the PROM contents
(well, partial contents - see below) from the "m8266_ucode.out.txt" file;
each uword entry starts with the lines:
***** PDP-11/34a micro code word for MPC = 000 *****
(MSB is left, indented fields generated by expansion ROMs)
micro word........ = 0000 0111 1100 0000 1100 1000 1010 0001 0000 0000 1110 0000
from ROM: E105 E103 E104 E100 E98 E97 E99 E106 E107 E108 E109 E110
The address of each uword is the "MPC = xxx" line; the contents of the 12
PROMs, at that address, are given on the "micro word........ = " line (the
PROMs are 4 bits wide).
If someone explained what format they needed as input for burning new PROMs,
I could easily (like an hour) write a small portable program (using StdIO
only, so it could be compiled and run on _anything_) that read that file in,
and spat out the 12 PROM files. (Most of the dump could be ignored - all the
data that's needed is in that one line.)
BUT (and this is why it would be good to get back to the source of that file),
that's not a complete M8266 ucode PROM dump.
The KD11-EA has a uword address space 1 bit larger than the KD11-E - almost
certainly to support floating point instructions; the KD11-EA adds 'uPC 09'
(although looking its source at the top of pg. 7 of the prints, I don't quite
grok how it is generated - maybe it's fed back through J2 from the FP11-A when
one is plugged in). Anyway, uword addresses run up to 02000 in the KD11-EA,
and the last uword in that dump is 0777.
Interestingly, according to the flow charts of the 'basic' KD11-E/EA ucode in
the prints (indexed and annotated here:
https://gunkies.org/wiki/KD11-E/EA_microcode
in full), they stop at 0757 - but the dump (in "m8266_ucode.out.txt")
contains uwords that are 'supposed' to be blank (per the flow charts),
as well as above 0757.
So that dump must have been prepared from a copy of the 'new' KD11-EA PROMs -
the ones including the floating point ucode. (Note that the FP11-A _also_
contains ucode, intended to control the stuff on the FP11-A; but the floating
point instructions _also_ use the KD11-A for some stuff - e.g. fetching
operands from main memory. Only the ucode address space is shared.)
> From: Warner Losh
> There's a small chance that the tools.tar.gz link on
> http://www.ak6dn.com/PDP-11/M9312/ has these, but that's for a
> different module so who knows.
Right, a _completely_ different card - a boot PROM, not a CPU; totally
un-related - and by a different person (Don North).
But just for completeness, I looked in "tools.tar.gz", and it's just
bootstrap PROM stuff.
Noel
You may recall that, a few weeks ago, I requested parts help (shopping
baskets) for
the Retro Chip Tester Pro that I got for Christmas. Well, today's mail
brought the last
few parts and I have finished and tested it. Wow! The only thing that it
doesn't do is
slice bread. It's great. I've put up a few pictures here:
http://wsudbrink.dyndns.org:8080/images/RCTPro/
I got the 4008 and 1702 adapters with it, but I'm pretty sure that I will
get the rest over
the next month or so. This is the latest HW version with the latest release
software.
Bill S.
PS: Thanks to everyone that helped with parts.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> So it sermsdectape heads are special. I don?t think Dec would have the desire to make them internally so they probably contractef with a company already set up to do that. Who were the big tape head manufacturers at that time? Does anyone know?
A photo of the back of a TU56 DECtape head can be seen at https://www.pdp8online.com/tu56/pics/head_label.shtml?small .
The head has a label on it that reads:
Western Magnetics
Glendale Calif.
Record
7282
I've never seen a TU56 in person and have no idea if they have separate read, write, and erase heads or some other combo. The "Record" notation on the above head's label hints to me this might be a write head.
I found that and other DECtape photos at https://www.pdp8online.com/tu56/tu56.shtml .
-- Ron
>
>
> Date: Tue, 8 Feb 2022 20:55:31 +0000
> From: Wayne S <Wayne.Sudol at hotmail.com>
> Subject: Re: DECTape head problem
>
> So it serms dectape heads are special. I don?t think Dec would have the
> desire to make them internally so they probably contractef with a company
> already set up to do that. Who were the big tape head manufacturers at that
> time? Does anyone know?
>
We have one from Applied Magnetics Corporation, maybe the one in Goleta, CA.
--
Michael Thompson
On 2/8/22 14:14, Wayne S via cctech wrote:
> Searched a lille bit for Western Magnetics. Here?s a site that has some surplus heads, even a western magnetics onebut probably not the correct one. There is a corporate charter record for Western Magnetics in Minnesota dated 1964. Maybe this is the same company. There?s also a tape head from Michigan Magnetics. Maybe a merged company?
>
> https://www.surplussales.com/Equipment/magnetic-tape.html
>
>
> Sent from my iPhone
>
> On Feb 8, 2022, at 13:05, Ron Pool via cctech <cctech at classiccmp.org> wrote:
>
> ?
> So it sermsdectape heads are special. I don?t think Dec would have the desire to make them internally so they probably contractef with a company already set up to do that. Who were the big tape head manufacturers at that time? Does anyone know?
>
> A photo of the back of a TU56 DECtape head can be seen at https://www.pdp8online.com/tu56/pics/head_label.shtml?small .
> The head has a label on it that reads:
> Western Magnetics
> Glendale Calif.
> Record
> 7282
>
> I've never seen a TU56 in person and have no idea if they have separate read, write, and erase heads or some other combo. The "Record" notation on the above head's label hints to me this might be a write head.
>
> I found that and other DECtape photos at https://www.pdp8online.com/tu56/tu56.shtml .
>
> -- Ron
>
>
Thanks.? Hadn't seen the Minnesota information.? Found some references
but not actual company info.? Did find a reference somewhere it Canada,
but I couldn't tell if it was original or successor company.? At any
rate, no web presence nor telephone numbers found (yet.)
I've dealt with the SurplusSales (of Nebraska) many times.? His prices
are usually pretty high (not obscene, but just not 'surplus' prices I'm
used to.)? However, he is a first-rate dealer and when he says something
is so, you can count on it.? Never had problem with anything I was
willing to *PAY* for.? I scanned the list you provided and found only a
few 'digital' devices, unfortunately.? I suspect from 7 and 9 track mag
tape drives.? I will scan his site and send him a ping so he'll be on?
the lookout.
-Gary
Hi
???????? Jerry Walker and I have an 11/34 under restoration.
We have run into a bit of a problem.
On the M8266 CPU control board a defective 7404 (E111) has killed a
bunch of the PROMs holding the microcode.
Does anybody have or can get images of the PROMs on this board so
replacement devices an be programmed.
Rod
I have many 8mm tapes. A few are new. First comers get new ones.
I have a few 8mm cleaning cassettes
I have about a dozen DLT-II tapes.
I have a Quantum DLT-II drive with wide SCSI LVD/SE interface
I have some Ultrium LTO fibre-channel SCSI drives that were removed
>from a tape-mounting robot several years ago. I never used them in my
computers. The mounting bracket for one was modified to have an
internal power supply -- which might be inadequate. ?I have one LTO
tape.
I have a 5.25" floppy drive.
Yours for the price of shipping, or local pickup OK.
Van Snyder
van.snyder at sbcglobal.net
La Crescenta, CA
> On Feb 8, 2022, at 5:14 PM, Wayne S via cctech <cctech at classiccmp.org> wrote:
>
> Searched a lille bit for Western Magnetics. Here?s a site that has some surplus heads, even a western magnetics onebut probably not the correct one. There is a corporate charter record for Western Magnetics in Minnesota dated 1964. Maybe this is the same company. There?s also a tape head from Michigan Magnetics. Maybe a merged company?
>
> https://www.surplussales.com/Equipment/magnetic-tape.html
Those all look like audio heads, nothing even vaguely resembling a DECtape head.
paul
> From: Steve at oldcomputers.net
> There are some vintage tablets in Minneapolis (Eden Prarire) that would
> like, but the seller will not ship.
> Any help?
When dealing with eBaiters who can't/won't ship, I have had good luck with
PakMail (http://www.pakmail.com/); for a usually reasonable fee, they will go
pick something up, package it properly, and ship it.
In my experience with them, the shipping cost may not have been the absolute
lowest possible I could have secured had I been on the spot, looking around,
but.. I wasn't on the spot, looking around. And they went to the person's
house, picked the thing up, and shipped it.
Noel
There are some vintage tablets in Minneapolis (Eden Prarire) that would like, but the seller will not ship.
Any help? You will have to pay, pick up, and ship.
I would do it for you!
Thanks-
Steve in CA
> On Feb 8, 2022, at 2:53 PM, Wayne S via cctech <cctech at classiccmp.org> wrote:
>
> Since so many audio tape players and computer magtape units were made it would stand to reason that there has to be a stash somewhere of tape heads and it?s just a matter of finding where they are.
> Are there any part numbers on the dectape heads?
The schematics are bound to show DEC part numbers, but how those translate into supplier part numbers is anyone's guess. Or perhaps they were made internaly by DEC?
In any case, DECtape heads are unusual. Computer tapes are normally 1/2 inch wide (a few old tape drives had different widths, like the 14 track 1 inch CDC tape). But DECtape and LINCtape are 3/4 inches wide, with 10 head positions.
Audio tapes are unlikely to be helpful; consumer reel to reel tape is 2 tracks (interleaved for when you flip over the reel?) 1/4 inch; professional decks might have 8 tracks or more on 1/2 or 1 or 2 inch wide tape, but I don't remember ever seeing 3/4 inch wide audio or instrumentation heads.
paul
On 2/7/22 12:48, Marc Howard via cctech wrote:
> The problem would be the non-standard track size and number of tracks.
> However if at least one of the head's paired tracks is good you could
> potentially cut the drive current in half and double the read amplitude and
> just use one track for the affected channel.
>
> Marc
>
> On Mon, Feb 7, 2022 at 12:33 PM Wayne S via cctech <cctech at classiccmp.org>
> wrote:
>
>> I?ve often wondered if the tape heads from consumer tape devices such as
>> cassette or 4-8 track tape players could be used or be made to be used as
>> replacements. Anybody ever try that?
>>
>> Sent from my iPhone
>>
>>> On Feb 7, 2022, at 11:51, Michael Thompson via cctech <
>> cctech at classiccmp.org> wrote:
Further, the DECTape had various track-to-track spacing.? Between the
the Mark track and the first data track on both edges, the spacing is at
a little less than twice that between the mark and timing tracks or
between each set of data tracks.? Put a different way, the track spacing is:
T.M..D.D.D.D.D.D..M.T
The magnetic poles of each head is roughly 1mm wide with about .8 mm
spacing heads? The '..' in the above means there is about 1.4mm spacing
(between 'M and D' and 'D and M', for example - the measurements are
crude, so I could be off 20% or more.)
I've searched the documents I have (many from bitsavers) and haven't yet
spied a specification for the head design.? I suppose if I could
determine the head 'gap' and knowing the magnetic flux required of the
tape (with proper margins) and knowing the stated impedance of the head
and drive current, I could figure out how many turns of some size wire
is required (looks to be at least as small as #40).
Back when I was a bit younger and less experienced (and didn't know it
was impossible,) I actually 'repaired' (for some definition of 'repair')
an old 1/4 inch tape head.? But all I did was pull some wire off the
coil and delicately soldered a tap to this wire.? It worked ok for a
couple of years but was obviously failed again from rough handling.?
Fortunately it was 'easy' since there wasn't a bunch of clear epoxy in
the way ;-)? I'm not sure today I would have the temerity to even try.
Hoping one will show up someday and I can make a deal as to complete my
unit.
Thanks to all who have replied.
-Gary
I wonder if there are any professional audio multi-track recorders that
match the tape width, number of tracks and tack pitch and have the
necessary frequency response.
On 2/7/2022 3:05 PM, Marc Howard via cctech wrote:
> 8 track tapes use 1/4" wide tape. Most 8 track units use heads with only
> two tracks implemented. There was a stepper solenoid that moved the head
> down (or up after all 4 stereo programs were played). Growing up in the
> 60s you never forget things like listening to In-A-Gadda-Da_Vida fade in
> the middle of the drum solo and a loud "klunk-klunk" sound and the song
> resuming.
>
> Some true 8 track heads were made for mastering pre-recorded tapes and
> maybe for consumer recorders.
>
> Marc
>
>
> On Mon, Feb 7, 2022 at 12:51 PM Michael Thompson via cctech <
> cctech at classiccmp.org> wrote:
>
>> DECtapes have 5x redundant tracks. If you could find an 8-track head that
>> had the same track pitch, and maybe track width, you could read the tape
>> but lose redundancy on the Mark and Timing tracks. That probably would not
>> work with a marginal DECtape.
>>
>> On Mon, Feb 7, 2022 at 3:33 PM Wayne S <wayne.sudol at hotmail.com> wrote:
>>
>>> I?ve often wondered if the tape heads from consumer tape devices such as
>>> cassette or 4-8 track tape players could be used or be made to be used as
>>> replacements. Anybody ever try that?
>>>
>>> Sent from my iPhone
>>>
>>>> On Feb 7, 2022, at 11:51, Michael Thompson via cctech <
>>> cctech at classiccmp.org> wrote:
>>>> ?
>>>>>
>>>>> From: Gary Oliver <go at aerodesic.com>
>>>>> Subject: DECTape head problem
>>>>>
>>>>> In debugging my DECtape interface lashup, I found that one of my head
>>>>> has two open windings.? Specifically, one channel has an open 'ground'
>>>>> with the other two lines apparently the full winding of the channel.?
>>>>> The second channel failing has no continuity between any of the three
>>>>> lines.? I have tested the other head and it has all the requisite
>>>>> continuity so I'm hoping I can at least get a single spindle running.
>>>>>
>>>>> Has any ever attempted repair of one of these?
>>>>>
>>>>> -Gary
>>>>>
>>>> At the Rhode Island Computer Museum we found several DECtape heads on
>>> TU55
>>>> and TU56 drives with open connections. A volunteer got one head X-Rayed
>>> so
>>>> we could see the solder joints between the tiny wires for the head
>> coils,
>>>> and the larger twinax wires that go to the relay board. We couldn't see
>>> any
>>>> damage to the wires or solder joints.
>>>>
>>>> We tried heating the potting material to soften it, and digging it out
>> to
>>>> get to the solder joints. While digging at the potting material you
>> can't
>>>> see the tiny wires, so they will likely get damaged.
>>>>
>>>> We considered using a solvent to remove the potting material, but
>> thought
>>>> that it would eat the enamel off the head coil wires and damage them
>>> beyond
>>>> repair.
>>>>
>>>> So far we haven't found a way to repair the heads.
>>>>
>>>> Michael Thompson
>>
>> --
>> Michael Thompson
>>
DECtapes have 5x redundant tracks. If you could find an 8-track head that
had the same track pitch, and maybe track width, you could read the tape
but lose redundancy on the Mark and Timing tracks. That probably would not
work with a marginal DECtape.
On Mon, Feb 7, 2022 at 3:33 PM Wayne S <wayne.sudol at hotmail.com> wrote:
> I?ve often wondered if the tape heads from consumer tape devices such as
> cassette or 4-8 track tape players could be used or be made to be used as
> replacements. Anybody ever try that?
>
> Sent from my iPhone
>
> > On Feb 7, 2022, at 11:51, Michael Thompson via cctech <
> cctech at classiccmp.org> wrote:
> >
> > ?
> >>
> >>
> >> From: Gary Oliver <go at aerodesic.com>
> >> Subject: DECTape head problem
> >>
> >> In debugging my DECtape interface lashup, I found that one of my head
> >> has two open windings.? Specifically, one channel has an open 'ground'
> >> with the other two lines apparently the full winding of the channel.?
> >> The second channel failing has no continuity between any of the three
> >> lines.? I have tested the other head and it has all the requisite
> >> continuity so I'm hoping I can at least get a single spindle running.
> >>
> >> Has any ever attempted repair of one of these?
> >>
> >> -Gary
> >>
> >
> > At the Rhode Island Computer Museum we found several DECtape heads on
> TU55
> > and TU56 drives with open connections. A volunteer got one head X-Rayed
> so
> > we could see the solder joints between the tiny wires for the head coils,
> > and the larger twinax wires that go to the relay board. We couldn't see
> any
> > damage to the wires or solder joints.
> >
> > We tried heating the potting material to soften it, and digging it out to
> > get to the solder joints. While digging at the potting material you can't
> > see the tiny wires, so they will likely get damaged.
> >
> > We considered using a solvent to remove the potting material, but thought
> > that it would eat the enamel off the head coil wires and damage them
> beyond
> > repair.
> >
> > So far we haven't found a way to repair the heads.
> >
> > Michael Thompson
>
--
Michael Thompson
>
> From: Gary Oliver <go at aerodesic.com>
> Subject: DECTape head problem
>
> In debugging my DECtape interface lashup, I found that one of my head
> has two open windings.? Specifically, one channel has an open 'ground'
> with the other two lines apparently the full winding of the channel.?
> The second channel failing has no continuity between any of the three
> lines.? I have tested the other head and it has all the requisite
> continuity so I'm hoping I can at least get a single spindle running.
>
> Has any ever attempted repair of one of these?
>
> -Gary
>
At the Rhode Island Computer Museum we found several DECtape heads on TU55
and TU56 drives with open connections. A volunteer got one head X-Rayed so
we could see the solder joints between the tiny wires for the head coils,
and the larger twinax wires that go to the relay board. We couldn't see any
damage to the wires or solder joints.
We tried heating the potting material to soften it, and digging it out to
get to the solder joints. While digging at the potting material you can't
see the tiny wires, so they will likely get damaged.
We considered using a solvent to remove the potting material, but thought
that it would eat the enamel off the head coil wires and damage them beyond
repair.
So far we haven't found a way to repair the heads.
Michael Thompson
I'm going through? a few of my ESDI? and MFM hard drives? and ran across?2 Maxtor? XT 2190 drives with? all of the Drive Id's (1-4) tie together with 1 long
jumper and the drives have the write protect jumper is installed.? Not sure what theywould have been used for ??? Both are the same.
Jerry
There is a nice looking IBM 129 keypunch on Ebay for what I think is a very
reasonable "buy it now" price of US$1799:
https://www.ebay.com/itm/333898748391
Shipping to Australia would be horrendous otherwise I would have bought it.
Best regards
Tom Hunter
I'm putting stuff together here and it's time to begin working on the
8/E. Looks like a pretty generic system but it has two odd boards.
Pair of g227 memory boards, 4 board CPU+Console board, serial board,
nothing too special.
But two odd Omnibus cards: One is a memory board, half populated, my
guess is it's enough memory to bring the computer to 32kw. The other is
an mets 303-0115-001. Bunch of 7400 series logic chips, nothing too
special.
Any idea what it might have been? Timeshare option? Something else? Not
a peripheral controller from what I can see.
C
On Thu, Feb 3, 2022 at 1:08 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. (John Ames)
> 2. Re: (Paul Koning)
> 3. Re: (Jon Elson)
> 4. Re: KMC11/DMC11 folllow up (Dave Mitton)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Feb 2022 10:20:25 -0800
> From: John Ames <commodorejohn at gmail.com>
> To: cclist at sydex.com
> Cc: cctalk at classiccmp.org
> Message-ID:
> <CABCBCvP8SX_1rB3FXVxZuXx1SUFTfiJBTqePd_SZiNeReX7PEw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
> I think "witch settings" is my new preferred term for this. They're
> certainly mysterious and arcane enough.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Feb 2022 13:30:33 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: John Ames <commodorejohn at gmail.com>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re:
> Message-ID: <B8F20F9C-A329-4CED-9A00-036EAA8F4D1A at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Feb 2, 2022, at 1:20 PM, John Ames via cctalk <cctalk at classiccmp.org> wrote:
> >
> >> Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
> > I think "witch settings" is my new preferred term for this. They're
> > certainly mysterious and arcane enough.
>
> Nice. It would be a good term to apply to VMS SYSGEN parameters that are documented as having units "microfortnights".
>
> paul
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 2 Feb 2022 16:49:42 -0600
> From: Jon Elson <elson at pico-systems.com>
> To: Paul Koning via cctalk <cctalk at classiccmp.org>
> Subject: Re:
> Message-ID: <b0989916-7493-481d-7c45-a696ce5ecc31 at pico-systems.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2/2/22 12:30, Paul Koning via cctalk wrote:
> >
> >>
> > Nice. It would be a good term to apply to VMS SYSGEN parameters that are documented as having units "microfortnights".
> >
> A footnote in the system config guide noted that ufortnights
> would be approximated at one second.
>
> Jon
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 2 Feb 2022 14:31:27 -0500
> From: Dave Mitton <dave at mitton.com>
> To: "cctech at classiccmp.org" <cctech at classiccmp.org>
> Subject: Re: KMC11/DMC11 folllow up
> Message-ID: <20220202193130.24EDC4E775 at mx2.ezwind.net>
> Content-Type: text/plain; charset="utf-8"
>
> Date: Tue, 1 Feb 2022 18:46:46 -0500
> From: Bob Smith <bobsmithofd at gmail.com>
> Subject: Re: KMC11/DMC11 folllow up
> Message-ID:
> I?ve been watching this thread go by, and never finding time to contribute?.
>
> I started in Aug 1977 and finished the CommIOP products from Bob and Harvey. Clarise was no longer involved.
> It was basically done, I just did the QA on them and released it. I did find some bugs in the debugger we provided.
>
> I basically did KMC software support, on and off, going forward. When the KMC-B came out (I think Remi did that)
> I rev?ed the tools. I also did a KMC Tools package for VMS. I tossed into that package a VMS line printer driver, I wrote as an example and POC, that ran multiples LP11s at significantly better speed. We ran that in our lab. The MIT LCS lab loved that.
>
> My memory is weak on things like the ?DMX? and other things that CSS did. The Lab Products group built some successful data collection products around the KMC.
>
> Attempts in the Comms HW group to do an updated UNIBUS DH never got off the ground. We (NAC) did pitch the idea of using the CommIOP-DZ to VMS, as a way to off-load character terminal loads, and they would have nothing to do with it. For whatever reasons, they did not like the idea of smart devices.
>
> That led to the attempt to build a ?universal? terminal concentrator based on an 11 networked into the system. That project was complicated by what it tried to integrate, and took too long to build. It was overtaken by the simpler LAT based products that DEC went forward with.
>
> George Conant, Bob Rosenbaum, and Pete Nesbeda left the company and founded Xyplex that fielded successful products in this space.
>
> I could go on, but ? I do have copies of the KMC Tools doc and maybe the CommIOPs, but no KMC hw docs.
> Dave.
>
> Sent from Mail for Windows
>
>
Hey Dave! I did not mention you because I was not sure you wanted to
recall those days! you are correct it was Remi Lisee doing the design,
I did the first line units, and then they were redone a few years
later. Glad you piped in!! Hope you are doing great! All of you guys
were brilliant, except Harvey, he was a royal pain, said with lots of
laughs we both got tired or burning roms!!
bob smith
> Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
I think "witch settings" is my new preferred term for this. They're
certainly mysterious and arcane enough.
Date: Tue, 1 Feb 2022 18:46:46 -0500
From: Bob Smith <bobsmithofd at gmail.com>
Subject: Re: KMC11/DMC11 folllow up
Message-ID:
<CAHtNYbXBRwrOQm2cH+T+CDn5nq3sZN+PQRa9fEMVhqQ=pAMDSw at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Yes! thank you! Nice, smart, and did good work despite the magateer, I
mean marketing dweeb.
I lost track of Harvey, Bob wen ont to start a company over in west
concord, can't recall the name, used some of his gear for projects in
the mid 80s.
I was designing a comms system in late 80s and heard Len Bosak had
started a company, had a couple of meetings with him, and went with hs
gear. Man those were fun post DEC projexcts.
bob smith (PDP8 engineering, DecComm (Stockebrand, VInce et al), small
systems, then of toe LCG for 2080...
On Tue, Feb 1, 2022 at 2:43 PM John Forecast <john at forecast.name> wrote:
>
> On Feb 1, 2022, at 8:20 AM, Bob Smith via cctalk <cctalk at classiccmp.org> wrote:
> >
> > KMC11 - Paul K cited the docs. It was a bit different from DMC CPU board
> > in both cycle time and in the use of ram versus prom.
> > Both boards/products used the 4bit Alu but I don't call that bit
> > slice, as the 2901 is more of a bit slice.
> > KMC and DMC are Harvard architecture based devices, as is the 11/60 CPU.
> > DMC and KMC benefited from the microcode work of Harvey Schlesinger,
> > Bob Rosenbaum, Richie Larry, and I think Clarise joined the team in
> > 77. Can't recall her last name.
>
> Patton? Harvey, Bob and Clarise joined the DECnet-RSX development team sometime in 77/78.
>
> John.
>
> > DMC had (when I left the project and it had been shipping for a year
> > or two) a 300NS cycle time, while the KMC had a 240NS cycle time
> > thanks to the instruction register I had suggested to remi as we were
> > thinking of a RAM based device because PROMS were a royal pain with 2
> > and 3 code changes a day. This change allowed the machine to begin to
> > access the next instruction as one was executing - there are no
> > interrupts in either board.
> > bob
>
I?ve been watching this thread go by, and never finding time to contribute?.
I started in Aug 1977 and finished the CommIOP products from Bob and Harvey. Clarise was no longer involved.
It was basically done, I just did the QA on them and released it. I did find some bugs in the debugger we provided.
I basically did KMC software support, on and off, going forward. When the KMC-B came out (I think Remi did that)
I rev?ed the tools. I also did a KMC Tools package for VMS. I tossed into that package a VMS line printer driver, I wrote as an example and POC, that ran multiples LP11s at significantly better speed. We ran that in our lab. The MIT LCS lab loved that.
My memory is weak on things like the ?DMX? and other things that CSS did. The Lab Products group built some successful data collection products around the KMC.
Attempts in the Comms HW group to do an updated UNIBUS DH never got off the ground. We (NAC) did pitch the idea of using the CommIOP-DZ to VMS, as a way to off-load character terminal loads, and they would have nothing to do with it. For whatever reasons, they did not like the idea of smart devices.
That led to the attempt to build a ?universal? terminal concentrator based on an 11 networked into the system. That project was complicated by what it tried to integrate, and took too long to build. It was overtaken by the simpler LAT based products that DEC went forward with.
George Conant, Bob Rosenbaum, and Pete Nesbeda left the company and founded Xyplex that fielded successful products in this space.
I could go on, but ? I do have copies of the KMC Tools doc and maybe the CommIOPs, but no KMC hw docs.
Dave.
Sent from Mail for Windows
There is a discussion of the origin of the term "partition" in storage
devices such as HDDs at:
https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p
artition%22_originate?
It seems clear it was used in memory well before HDDs but when it got
started there is unclear.
* IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
support of HDDs
* UNIX, Apple OS's and IBM mainframe all seem to come later.
Partitioning as a "slice" probably predates IBM PC DOS v2
Would appreciate some recollections about DEC usage, other minicomputers and
the BUNCH.
You can either post directly to Wikipedia or let me know; links to
references would greatly be appreciated
Tom
> From: Tom Gardner
> You define logical disks by assigning a logical disk unit number to a
> file on a physical disk. You can then use the logical disk as though it
> were a physical disk.
To me, 'partition' implies a contiguous are of the disk; "a file" to me
implies that it might not be contiguous? Or are files contiguous in the RT-11
filesystem? (I know there were filesystems which supported contiguous files.)
This reminds me of the swapping/paging area in Windows 95/98 (maybe other
versions too), which was kept in a file, and therefore might be scattered all
over the physical disk. (Norton disk optimizer would coalesce the swap/paging
area to a contiguous area of the disk.)
Noel
KMC11 - Paul K cited the docs. It was a bit different from DMC CPU board
in both cycle time and in the use of ram versus prom.
Both boards/products used the 4bit Alu but I don't call that bit
slice, as the 2901 is more of a bit slice.
KMC and DMC are Harvard architecture based devices, as is the 11/60 CPU.
DMC and KMC benefited from the microcode work of Harvey Schlesinger,
Bob Rosenbaum, Richie Larry, and I think Clarise joined the team in
77. Can't recall her last name.
DMC had (when I left the project and it had been shipping for a year
or two) a 300NS cycle time, while the KMC had a 240NS cycle time
thanks to the instruction register I had suggested to remi as we were
thinking of a RAM based device because PROMS were a royal pain with 2
and 3 code changes a day. This change allowed the machine to begin to
access the next instruction as one was executing - there are no
interrupts in either board.
bob
> From: Paul Koning
> When did Unix first get partitions?
'Partitions' the mechanism, or partitions the term for the mechanism?
The former appeared about V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c
when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16 blocks,
so the 406*10*20 blocks of an RP03 had to be split up into partitions (called
'sections' or 'pseudo-disks' in the documentation) to make all of it useable.
The latter? No idea...
Partitions may have appeared in DOS/Windows for much the same reason; with 32
KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
having to use partitions when I bought a 13GB hard drive for my Windows 95
machine (FAT32 only came in with Windows 95 OSR2).
Noel
A somewhat broader search found the 1984 RT-11 System Release Notes with the following:
1.4.2.4 Logical Disk Subsetting Handler (LD) - The logical disk subsetting handler lets you define logical disks, which are subsets of physical disks. You define logical disks by assigning a logical disk unit number to a file on a physical disk. You can then use the logical disk as though it were a physical disk.
AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf (bitsavers.org) <http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.1_Jul84/AA-5286F-TC-T1_RT-11…> p15/102
Suggests DEC had not yet adopted the term ?partition? for a segment of a disk
Tom
-----Original Message-----
From: Tom Gardner [mailto:tom94022 at comcast.net]
FWIW a Google search: "partition site:http://www.bitsavers.org/pdf/dec/pdp11/rt11" returns no relevant hits prior to 1983
I suspect that ESDI and MFM controllers emulating RL/RK disks are also later than 1983
Tom
-----Original Message-----
From: Zane Healy [ <mailto:healyzh at avanthar.com> mailto:healyzh at avanthar.com]
Sent: Monday, January 31, 2022 12:40 PM
To: Paul Koning; General Discussion: On-Topic and Off-Topic Posts
Cc: <mailto:t.gardner at computer.org> t.gardner at computer.org; Tom Gardner
Subject: Re: Origin of "partition" in storage devices
On Jan 31, 2022, at 11:28 AM, Paul Koning via cctalk < <mailto:cctalk at classiccmp.org> cctalk at classiccmp.org> wrote:
>
> Both of these are memory partitions. The only OS I can think of predating the ones you mentioned is RT-11, the later versions (V2 did not have them). When did Unix first get partitions?
>
> paul
Partitions are pretty important in RT-11 v5.x, after all, there is the partition size limit, so you have to have multiple partitions for almost any HD, except very small ones.
Let?s not forget hardware enforced partitioning, the WEQSD/04 ESDI controller comes to mind. It see?s a single large ESDI HD as a single disk, but you can partition it on the controller, and the OS sees each partition as a separate physical disk. I seem to remember some MFM controllers that made the MFM drive appear to be RL01/RL02 or RK05 packs.
Zane
Anyone got any 8i switch or panel parts they Wana trade for any of these?
Got 6 3 pin spring loaded rockers appear to test good might need some
deoxot not sure came off the 8e below
8 of the 8e m rocker paddles orange and redish orange
https://drive.google.com/file/d/1Eprlv8d3TmSPFJ3rCHIJTFkQOyAZesCM/view?usp=…
Some are missing the plastic pivot dimples
8m with out it's switches
The rotory it's bit weird but possibly usable. Dunno enough about them.
It's center hole is ovaled a bit might gotten bashed. Might have some
usefull bits still
https://drive.google.com/drive/folders/1EpAag1J5r6RAR8ln_fprrdCEiOnJx5kq
I've got some other bits that might be usefull as well from the 8i to
anyone
I'm looking for 5 more rockers with or with out the 8i paddles
Or some 8i paddles I've got 5 brown and 10 white ones that I wanted to find
when I rescued my poor 8i outs the mud
Or any other parts that might be usefull
> From: Bob Smith
> the original UART was designed by DEC, Vince Bastiani was the project
> lead and designer, Gordon Bell was behind the project, and it may have
> been his idea.
"Computer Engineering: A DEC View of Hardware Systems Design" covers this, in
a footnote on pg. 73.
I seem to recall reading that Ken Olsen was involved in doing early modem
work (presumably on Whirlwind), but maybe my memory is failing, and it was
someone else (like Bell, or someone). Too busy to research it at the moment...
Noel
While moving some things around I found the following:
7 M8588
6 M8591
6 M8592
4 M8593
14 M8594
All appear to be NOS.
I also found :
G103
G222
G223
M911
Which I did not count, and they seem to be memory related, but I
haven't checked to see which memory they are from. If you have any interest
please contact me off list.
Thanks, Paul
> From: Chris Zach
> Maybe that is the dhv11.
The DH11, DHV11 and DHU11 are all very similar, although not 100.00% program compatible.
(The DHQ11 can be set to exactly emulate either the DHV11 or DHU11.) So, all provide
DMA output, but not DMA input.
Differences with the DH11 include two full word registers for DMA address,
hardware ^S/^Q support, built-in diagnostics, etc. The DHV11 and DHU11 differ
in hardware echo, output FIFO, a fix for the infamous DH11 input silo level
bug, etc.
Noel
In order to further the effort of scanning and preserving ALL of the
things, I picked up a Canon Microfilm Scanner 300 for $cheap. It has
a SCSI interface and doesn't work with anything past Windows XP, but
that's not a problem. What is a problem is that Canon's link to the
XP driver is a big 4 0 4:
https://www.usa.canon.com/internet/portal/us/home/support/details/scanners/…
By any chance, does someone out there have this driver? The filename
in question is "300350DRIT_V11.exe". You can google that name and end
up either back at Canon's site or in Malware Hell ("just download this
Chrome plugin to get your driver!").
Note that this is not the Canon Microfilm Scanner 300-II, which is a
USB device and uses a different driver.
Thanks for any leads...
jt
IIRC, John Mac was the designer for the DHQ/DHV. If my memory is
correct, after DH was done, John had the idea of a mix and match
synchronous/Async mux and came up with those designs. I dont remember
who was on his team. COMMS 11 group had led (farmed out) the designs
of the Sync version of a UART called USynRT in some parlance SIg 2652
and SMC 5027 IIFC. I ran the Signetics contract tech side. A fresh MIT
PhD was the Sig POC, and there are more stories about that. I cant
recall his name at this juncture.
bob
On Sun, Jan 30, 2022 at 1:00 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: What was a Terminal Concentration Device in DEC's
> products? (Noel Chiappa)
> 2. Re: What was a Terminal Concentration Device in DEC's
> products? (Paul Koning)
> 3. Re: What was a Terminal Concentration Device in DEC's
> products? (Chris Zach)
> 4. Re: What was a Terminal Concentration Device in DEC's
> products? (Glen Slick)
> 5. Re: What was a Terminal Concentration Device in DEC's
> products? (Noel Chiappa)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 29 Jan 2022 15:58:53 -0500 (EST)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <20220129205853.15EEA18C07B at mercury.lcs.mit.edu>
>
> > From: Paul Koning
>
> > DH-11 is unusual in that it has DMA in both directions
>
> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
>
> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
>
> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
>
> Noel
>
> PS: I am familiar with the term 'terminal concentrator' from the networking
> world, but as a generic term, not the name of a particular product. (Although
> Cisco's first boxes may have included a terminal concentrator, so named.)
>
> Noel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Jan 2022 17:12:41 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: Noel Chiappa <jnc at mercury.lcs.mit.edu>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <684F1FCF-A6E6-4F3C-AC39-ADA1504FC9E1 at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> >
> >> From: Paul Koning
> >
> >> DH-11 is unusual in that it has DMA in both directions
> >
> > McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> >
> > http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> >
> > it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
>
> Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
>
> paul
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 29 Jan 2022 18:49:06 -0500
> From: Chris Zach <cz at alembic.crystel.com>
> To: Paul Koning <paulkoning at comcast.net>, "General Discussion:
> On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>, Paul Koning via
> cctalk <cctalk at classiccmp.org>, Noel Chiappa
> <jnc at mercury.lcs.mit.edu>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <24F062E4-8B26-4EB3-A573-B47C69A53B67 at alembic.crystel.com>
> Content-Type: text/plain; charset=utf-8
>
> Maybe that is the dhv11. Or the dv11 I'll look it up tomorrow
>
> On January 29, 2022 5:12:41 PM EST, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
> >
> >
> >> On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> >>
> >>> From: Paul Koning
> >>
> >>> DH-11 is unusual in that it has DMA in both directions
> >>
> >> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> >>
> >> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> >>
> >> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
> >
> >Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
> >
> > paul
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ------------------------------
>
> Message: 4
> Date: Sat, 29 Jan 2022 16:47:27 -0800
> From: Glen Slick <glen.slick at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID:
> <CAM2UOwL2hi2Crm7ovphGd+UZFPePV+vUzoduan7a2a5Xo+eimw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> http://www.bitsavers.org/pdf/dec/qbus/EK-DHQ11-UG-002.pdf
> DHQ11 User Guide, EK-DHQ11-UG.002
>
> The main application of the M3107 DHQ11 is for interactive terminal
> handling; it can also be used for data concentration and real-time
> processing. It has two programming modes, DHV11 and DHU11. The
> register sets in these modes are compatible with those of the DHV11
> and DHU11 respectively. The preferred mode of operation is DHU11 mode.
> The main features of the DHQ11 are:
>
> ? For transmission: DMA transfers; or for each line, program transfers
> to a 1 character transmit buffer in DHV11 mode, or to a 64-character
> transmit FIFO in DHU11 mode
>
> ? For receive: a 256-entry FIFO buffer for received characters,
> dataset status changes, and diagnostic information
>
> The M3118 CXA16 and the M3119 CXA08 have the same programming
> interface as the M3107 DHQ11
>
>
> The M3108 DSV11 can do DMA transfers in both directions, although it
> is a synchronous interface, not asynchronous.
>
> http://www.bitsavers.org/pdf/dec/qbus/EK-DSV11-TM-001_Jan87.pdf
> DSV11 Technical Manual, EK-DSV11-TM-001
>
> Functional Description (Section 1.5). The DSV11 supports a range of
> synchronous protocols on the serial interface, and transfers data to
> and from the host by DMA transfer. This section describes the way in
> which the DSV11 handles data.
>
> On Sat, Jan 29, 2022 at 3:49 PM Chris Zach via cctalk
> <cctalk at classiccmp.org> wrote:
> >
> > Maybe that is the dhv11. Or the dv11 I'll look it up tomorrow
> >
> > On January 29, 2022 5:12:41 PM EST, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
> > >
> > >
> > >> On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> > >>
> > >>> From: Paul Koning
> > >>
> > >>> DH-11 is unusual in that it has DMA in both directions
> > >>
> > >> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> > >>
> > >> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> > >>
> > >> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
> > >
> > >Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
> > >
> > > paul
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 30 Jan 2022 09:26:46 -0500 (EST)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <20220130142646.5614818C074 at mercury.lcs.mit.edu>
>
> > From: Chris Zach
>
> > Maybe that is the dhv11.
>
> The DH11, DHV11 and DHU11 are all very similar, although not 100.00% program compatible.
> (The DHQ11 can be set to exactly emulate either the DHV11 or DHU11.) So, all provide
> DMA output, but not DMA input.
>
> Differences with the DH11 include two full word registers for DMA address,
> hardware ^S/^Q support, built-in diagnostics, etc. The DHV11 and DHU11 differ
> in hardware echo, output FIFO, a fix for the infamous DH11 input silo level
> bug, etc.
>
> Noel
>
>
> End of cctalk Digest, Vol 88, Issue 30
> **************************************
Back in 75-77 time frame, the KMC11 was packaged with DD11 backplane,
a controller interface board or an SLU to implement version 2 of the
DoD AUTODIN II. Philco Ford element then called Aeronuetronic Ford out
ot Cali was the prime. DEC won the hardware portion bidding PDP11
systems using the KMC11 and SLUs ranging from Mode1 to Mode VI. I did
the SLUs for Mode VI (ADCCP/SDLC et al) and Mode II (BiSync) out of
the Comms 11 group. CSS Nashua did the Async system with I think 64
lines, or more, and labeled it DMX IIRC - my memory could be bad on
the name.The COMM IOP concept was another alternative using the DZ/DU
boards. Barney Loiter, if he is still around can probably remember
who in CSS did the product. I think Frank Zareski, who had moved from
Comms group to Semiconductor was involved with or the lead for the
DUAL UART chips DEC invented (point for the record, the original UART
was designed by DEC, Vince Bastiani was the project lead and designer,
Gordon Bell was behind the project, and it may have been his idea.)
On Sat, Jan 29, 2022 at 1:00 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: simulation of an entire IBM S/360 Model 50 mainframe
> (Curious Marc)
> 2. What was a Terminal Concentration Device in DEC's products?
> (Chris Zach)
> 3. Re: What was a Terminal Concentration Device in DEC's
> products? (Paul Koning)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Jan 2022 20:53:22 -0800
> From: Curious Marc <curiousmarc3 at gmail.com>
> To: Liam Proven <lproven at gmail.com>, "General Discussion: On-Topic and
> Off-Topic Posts" <cctalk at classiccmp.org>
> Subject: Re: simulation of an entire IBM S/360 Model 50 mainframe
> Message-ID: <E6C6C3FB-E0A0-4472-A485-3EA9E1102CEC at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Ah, it was you Liam. Ken is enamored with the new title you bestowed on him. He will now be officially called: Master Ken, Hardware Boffin.
> :-)
> Marc
>
> > On Jan 27, 2022, at 11:54 AM, Liam Proven via cctalk <cctalk at classiccmp.org> wrote:
> >
> > ?On Thu, 27 Jan 2022 at 17:20, Guy N. via cctalk <cctalk at classiccmp.org> wrote:
> >>
> >> This might be old news to a lot of people here, but I noticed a fun
> >> article on The Register today:
> >
> > Oh cool. Thanks for the link -- that's one of my stories. Glad to hear
> > people enjoyed it. :-)
> >
> > --
> > Liam Proven ~ Profile: https://about.me/liamproven
> > Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
> > Twitter/LinkedIn: lproven ~ Skype: liamproven
> > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Jan 2022 00:28:30 -0500
> From: Chris Zach <cz at alembic.crystel.com>
> To: CCTalk mailing list <cctalk at classiccmp.org>
> Subject: What was a Terminal Concentration Device in DEC's products?
> Message-ID: <ba6ec80e-e099-4015-9d58-f33fb4e51c02 at alembic.crystel.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Old question: I'm looking through some old reports from 1977 about a
> failed DEC project with the DMX11 multiplexer system and there is
> reference to the following key items:
>
> 1) The DMX was designed to handle block mode devices. Fine.
> 2) Character mode devices like the VT52's were supposed to use a "TCD"
> product from DEC.
>
> The reason the project imploded was because apparently DEC stopped
> supporting the TCD in RSX11/D in late 1976, so someone in CSS had the
> great idea of agreeing to extend the microcode in the DMX11 to handle
> both block AND character mode devices. This did.... not work well and it
> sank the project.
>
> What I'm wondering is what was the TCD for PDP11's back then? I don't
> see anything in my communications handbooks on this, and even the DMX11
> doesn't really appear, instead there is the COMM/IO/P type boards which
> worked with a pile of DZ11's. From what I can glean from this
> documentation it looks like the DMX11 worked in a similar fashion as the
> requirement was the DMX11 system was a nine board solution (possibly 8
> DZ11's and one controller board).
>
> More odd it looks like the TCD *was* still supported in RSX11/M and
> ultimately the decision was made to build the thing in M so it's weird
> they continued to whack away at the DMX solution instead of going with
> TCD's for async and proven DMX microcode for block devices.
>
> Any thoughts, or does this jog any memories?
>
> C
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 29 Jan 2022 10:24:56 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: Chris Zach <cz at alembic.crystel.com>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <7F4B4A3F-4114-4FF9-9D6C-28AA7E26E475 at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Jan 29, 2022, at 12:28 AM, Chris Zach via cctalk <cctalk at classiccmp.org> wrote:
> >
> > Old question: I'm looking through some old reports from 1977 about a failed DEC project with the DMX11 multiplexer system and there is reference to the following key items:
> >
> > 1) The DMX was designed to handle block mode devices. Fine.
> > 2) Character mode devices like the VT52's were supposed to use a "TCD" product from DEC.
> >
> > The reason the project imploded was because apparently DEC stopped supporting the TCD in RSX11/D in late 1976, so someone in CSS had the great idea of agreeing to extend the microcode in the DMX11 to handle both block AND character mode devices. This did.... not work well and it sank the project.
> >
> > What I'm wondering is what was the TCD for PDP11's back then? I don't see anything in my communications handbooks on this, and even the DMX11 doesn't really appear, instead there is the COMM/IO/P type boards which worked with a pile of DZ11's. From what I can glean from this documentation it looks like the DMX11 worked in a similar fashion as the requirement was the DMX11 system was a nine board solution (possibly 8 DZ11's and one controller board).
> >
> > More odd it looks like the TCD *was* still supported in RSX11/M and ultimately the decision was made to build the thing in M so it's weird they continued to whack away at the DMX solution instead of going with TCD's for async and proven DMX microcode for block devices.
> >
> > Any thoughts, or does this jog any memories?
>
> Nothing comes to mind here; the name "DMX" does not ring any bells. It's a bit before my time, admittedly.
>
> DEC made some products that used block mode terminals: the moderately successful Typeset-11 with the VT-61/t forms and page editing terminal, and the VT-71 with embedded LSI-11 to do full file local editing. Both have some form of block transfer to the host, but as far as I can remember they used ordinary DH-11 terminal interfaces. DH-11 is unusual in that it has DMA in both directions, which is unhelpful for interactive use but great for block transfer. Typeset-11 also supported a specialized terminal made by Harris (the 2200), another local processor device, this one connected to the PDP-11 host with a DL-11/E, using half duplex multidrop BISYNC with modem signal handshakes. I kid you not... I have some scars debugging that protocol at 2 am in downtown Philadelphia.
>
> DEC also built yet another VT-51 variation, the VT-62, which was the terminal for the TRAX system. That was, I think, some sort of RSX derivative (-M+ perhaps, but I'm not sure), which made it to field test but was canceled before becoming an official product. Not sure why.
>
> paul
>
>
>
>
> End of cctalk Digest, Vol 88, Issue 29
> **************************************
> From: Paul Koning
> DH-11 is unusual in that it has DMA in both directions
McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
Noel
PS: I am familiar with the term 'terminal concentrator' from the networking
world, but as a generic term, not the name of a particular product. (Although
Cisco's first boxes may have included a terminal concentrator, so named.)
Noel
Old question: I'm looking through some old reports from 1977 about a
failed DEC project with the DMX11 multiplexer system and there is
reference to the following key items:
1) The DMX was designed to handle block mode devices. Fine.
2) Character mode devices like the VT52's were supposed to use a "TCD"
product from DEC.
The reason the project imploded was because apparently DEC stopped
supporting the TCD in RSX11/D in late 1976, so someone in CSS had the
great idea of agreeing to extend the microcode in the DMX11 to handle
both block AND character mode devices. This did.... not work well and it
sank the project.
What I'm wondering is what was the TCD for PDP11's back then? I don't
see anything in my communications handbooks on this, and even the DMX11
doesn't really appear, instead there is the COMM/IO/P type boards which
worked with a pile of DZ11's. From what I can glean from this
documentation it looks like the DMX11 worked in a similar fashion as the
requirement was the DMX11 system was a nine board solution (possibly 8
DZ11's and one controller board).
More odd it looks like the TCD *was* still supported in RSX11/M and
ultimately the decision was made to build the thing in M so it's weird
they continued to whack away at the DMX solution instead of going with
TCD's for async and proven DMX microcode for block devices.
Any thoughts, or does this jog any memories?
C
This might be old news to a lot of people here, but I noticed a fun
article on The Register today:
Hardware boffin is building a simulation of an entire IBM S/360 Model 50
mainframe
https://www.theregister.com/2022/01/27/ibm_s360_simulation/
The article has a handy link to a post on Ken Shirriff's blog:
https://www.righto.com/2022/01/ibm360model50.html
While I'm kind of a "DEC guy", I still have a certain nostalgic fondness
for the IBM System/360, since that was my first in-depth exposure to
computer programming.
Some years ago I was on a mission to rack mount all my computer and test equipment. I found three front panels at a hamfest that I planned to use. I never did anything with them but still have them. These are from Datum systems, but they appear to be rather hard to find much information on.
The short story is, if anyone needs them for something, let me know. I would hate to do away with them if someone needs them. Two of the panels are marked:
Datum, inc Rotating Drum Memory 6008
Datum, inc Data Acquisition System 120
The last isn't marked.
A picture is here:
http://wrcooke.net/FrontPanels.jpg
I will likely be moving in a few months and these are on the "get rid of" list.
Thanks,
Will
I've always thought the physical tape wound on a DECtape spool was a
fairly conventional 'sandwich' of mylar/oxide/mylar, but a recent 'test'
makes me think there is something else involved.
I have a number of tapes I'm cleaning (removing dust, etc.)? to make
ready to read on a restored (apparently) Astrotype dual DECtape drive
and I was 'dressing' the leaders of the tape (removing ragged bits from
old use.)? After trimming a wee bit from several tapes (.5 to 1 inch) I
did a test.? Taking the bits of tape, I exposed them to various
concentrations of isopropanol/water (from about 25% to 99% iso) and
found than in all cases, some of the data side of the tape came off on
the wipe.? The remaining tape fragment appears intact - the brown oxide
was still there but both sides were now the same color, rather than the
data side being darker (as were all my tapes before the test.)
Was there some kind of 'lubricating' coat on the data side?? It makes
sense, but none of my DEC documents or Googling has any mention of
lubrication, other than the "...hydro- dynamic lubrication, relying on
the viscosity of air to entrain it with the tape and provide the
flotation medium." found in an "ELECTROMECHANICAL COMPONENTS & SYSTEMS
DESIGN" from November,? 1964.
All of my tapes, including DECtape brand, Scotch brand and even a couple
of old "Microtape" brand from DEC (before 'dectape' name change) have
this feature, so this doesn't appear to be something that appeared
recently (as in late in DECtape production or due to old-age in the tapes.)
If someone has some detail information on the tape construction, I'd am
curious to see it.
Thanks,
Hello,
I had picked up these machines fresh out of high school. I actually worked
a deal with the buyer to make payments out of my paycheck for a few weeks
till they were paid in full. i have not had the time to focus and get them
running.
one machine i have had up to the cpu monitor, no internal disk drive.
the second machine has some corrosion on the front panel board, where the
battery leaked. it iminimal, and the bad battery is removed.
open to offers.
located in US Florida
Looking to sell off excess stuff, i want to focus on my pdp11's and
mainframes.
Going through an old junk pile, I came across a couple of core boards:
Micro Memory, Inc.
PN 90360 8K*8 (MM-6800)? Date code 7725
I have two boards (s/n 202 and 203) so likely purchased in pairs.
Anyone have any information on these?? They have 86 pin connectors so
not S-100 though connector is about the same size.
For years, these have sit on a shelf on my 'round tuit' list of bringing
them up in one of my old S-100 boxes, so I've been cruising along
thinking these were 100 pin connectors.? I got them out today so I could
find the manual (I have used the MMI s-100 8kx8 boards in an old company
project back in 1977 and those were about the same size and form.)? The
core board is a daughter board on top of the board with the bus
connector and is likely the same module from the S-100 board.? I'm
guessing the 86 pin bus is a Motorola Exorciser bus - so I can probable
figure it out from there, but I would like to find a manual.
I think my company had an Exorciser development system in the late 70s.?
These were obtained from a dumpster dive.? Pity I didn't get the rest of
the box, if so.
As usual, google wasn't extremely helpful with old pedestrian hardware
searches.
-Gary
> From: Gary Oliver
> I've always thought the physical tape wound on a DECtape spool was a
> fairly conventional 'sandwich' of mylar/oxide/mylar ...
> Was there some kind of 'lubricating' coat on the data side? It makes
> sense, but none of my DEC documents or Googling has any mention of
> lubrication ...
> If someone has some detail information on the tape construction, I'd am
> curious to see it.
Dunno if you know of this:
http://www.bitsavers.org/pdf/dec/dectape/3M_DECtape_Spec_Nov66.pdf
but it doesn't mention any lubrication, just a "Protective Overlay" layer,
over the "Coating" (which I assume is the oxide). I'm a bit surprised that
"some of the data side of the tape came off on the wipe", though, unless the
"various concentrations of isopropanol/water" dissolved the Protective
Overlay.
Noel
Hi,
I have a mystery S-100 computer that I'm would like to sell, from the
estate of the late Ken Gielow (author of Z80DIS, a great Z80 disassembler).
The proceeds will be donated to a non-tax-deductible magic group Ken was a
long-time member of.
The computer is located in Cupertino, CA (aka "the heart of Silicon
Valley", in the S.F. Bay Area). (If reopened, you can combine a pickup
with a visit to the Computer History Museum in nearby Mountain View, CA! :)
This would likely be quite expensive to ship. I'd guess 30+ pounds.
Photos and some info at:
www.sieler.com/ken_photos
Some of the hardware (also listed on the above page):
ThinkerToys buss
unknown semi-transparent front panel
spare/uninstalled Ithaca Intersystems DPS-1 front panel
10 various boards inside
metal case (heavy)
There may be manuals on some of the boards and/or the Ithaca, but I'm not
sure yet. (They would be included, if they exist.)
I wanted to take photos of each board, but having been seated for about 40
years, they don't come out if I tug gently. None have integrated board
lifters, unfortunately
(I tried a boroscope, but could not get useful photos.)
Based on the labels on some EPROMS, there's a chance that it's a homebrew
TRS-80 clone, with both Level II BASIC and CBASIC, and may have Morrow
DISCUS software on it.
We're looking for an offer on either:
- the Ithaca Intersystems front panel;
- the computer with all the boards
or both.
Suggestions welcome, thanks!
> From: Gary Oliver
> Paul - thanks for the bitsavers reference.
Ahem!
In any case, it's Al who really deserves the credit, for finding that document, and
putting it up.
Noel
> From: Gavin Scott
> I think if I had a whole lot of old faded greenbar etc. ... Someone may
> even have done this already
See:
https://walden-family.com/impcode/imp-code.pdf
Someone's already done the specialist OCR to deal with faded program listings.
Noel
I am trying to locate documentation on the PDP-8 clone built by Canadian company Consolidated Computer Inc (Mers Kutt) in the mid 1970's.
An example exists in the UK and will be restored when more data than just the system can be found.
Rod Smallwood - digital equipment corporation 1975-1985
Would someone please suggest a replacement for the Compaq Portable's
brightness knob? This was missing on mine when I got it.
--
David Griffith
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
So now that my pdp8/L is up and running (it now has a serial port and
runs FOCAL69 quite well) I'm thinking about the next step, which is of
course more memory.
This requires a BA08 or BM8/L or something expansion box but to be
honest I have enough spare flip chips and such from the wrecked 8/I to
build about 3 core memory systems. So given that the schematics for the
BA08 are online, they look pretty darn simple, I have the parts, and I
have the parts does anyone know if it's possible to get a flip chip
backplane to work on and wire up to emulate a BA08?
It looks like they just used the data break interface lines to hook up
to the processor. Everything's there, Memory address bus, memory data
bus, and the various signals for jumps and the like that could allow one
to decode and implement the extra instructions needed.
Hm. Might just be easier to build it with an FPGA or something as it's
mostly linking up simple gates and the whole core memory section could
be removed by a 4k*12 memory array. Anyone ever done this?
C
> This:
> https://www.ebay.com/itm/275084268137
> ...
> Anyway I fully expect it to go ... for a _lot_ more than the opening price.
Much to my surprise, it didn't sell at all (although a number of other lots,
likely from this machine, did.)
I'm rather puzzled that an -11/70 will sell for north of $10K, while a /780
can't fetch $5K. I can only guess that PDP-11'S are seen as more important in
the collector world (even though the BSD work, which had such a huge impact on
UNIX, which has now - in the form of Linux - taken over the world, was
centered on the VAX).
Noel
https://i.imgur.com/48EfOQG.jpg
That's after sitting parked a couple months. I have a Dysan doing it too. The Dysan had been re-banded with a boiled 3M band and run for years like that with no shedding. I have another Dysan with a green Plastiband in it which is also fine, minimal/no shed. So, I think we may need to re-evaluate if the clear Amazon cheap "plastibands" are perhaps totally incompatible with tape.
I know, I know..."just use the band to get data off." But I want to *run* QICs without having to destroy them constantly.
Thanks,
Jonathan
I think I may need to replace the two output capacitors in some of my H744
regulators. These are screw terminal 6,000uF 10V parts. I have looked on
Mouser, Farnell and Digikey and there don't seem to be any available, and
any that are listed are really rather costly.
Does anyone know where I might find some, preferably from a reputable
supplier. Note that I am in the UK.
If I can't find 10V rated ones, then, generally up to what sort of voltage
rating can I go? Of course, physical size will be a factor, but electrically
can it affect operation of the regulator if the rated voltage is too high?
Thanks
Rob
I am in the process of thinning down my vintage computer holdings, to relieve some of the burden I will leave to my heirs (hopefully not too soon!).
I have a working tiny PDP-11/73 system available for sale. I would much prefer not to have to break it down and pack it for shipping, but I will if the buyer agrees to pay for the packing and shipping costs.
- - - - -
Tiny PDP-11/73 System:
H9281-BA backplane and card cage
KDJ11-A CPU
DLV11-J 4 port SIO
MSV11-LK 256KB/128KW memory
Emulex UC07 SCSI interface
Power-on Reset board from here:
http://www.heeltoe.com/index.php?n=Pcbs.Qbus-por
SCSI-to-SD hard drive emulator with 4 drives available, RT-11 installed
MeanWell RT-125B power supply
4.5 inch AC fan
qty 4 GlitchWorks serial cables
Spare PDP-11/23 CPU saved as a backup:
KDF11-AB CPU
RT-11 Pocket Guide
RT-11 Mini-Reference Manual
- - - - -
I am asking $800.00 for the lot. It cost me about that, probably more to acquire it piece-by-piece and assemble it into a working system.
smp
- - -
Stephen Pereira
Bedford, NH 03110
KB1SXE
Would someone please suggest a suitable screw specification for the Compaq
Portable keyboard? My restoration project was interrupted and I managed
to lose the screws.
--
David Griffith
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
I'm looking for a manual I can't find on Bitsavers: a DECnet/10 programming manual. The reason: trying to read PSTHRU.MAC and realizing that I was trying to understand DECnet-10 code while reading the DECnet-20 programming manual. Oops.
paul
I am in the process of thinning down my vintage computer holdings, to relieve some of the burden I will leave to my heirs (hopefully not too soon!).
I have a working tiny PDP-11/73 system available for sale. I would much prefer not to have to break it down and pack it for shipping, but I will if the buyer agrees to pay for the packing and shipping costs.
- - - - -
Tiny PDP-11/73 System:
H9281-BA backplane and card cage
KDJ11-A CPU
DLV11-J 4 port SIO
MSV11-LK 256KB/128KW memory
Emulex UC07 SCSI interface
Power-on Reset board from here:
http://www.heeltoe.com/index.php?n=Pcbs.Qbus-por <http://www.heeltoe.com/index.php?n=Pcbs.Qbus-por>
SCSI-to-SD hard drive emulator with 4 drives available, RT-11 installed
MeanWell RT-125B power supply
4.5 inch AC fan
qty 4 GlitchWorks serial cables
Spare PDP-11/23 CPU saved as a backup:
KDF11-AB CPU
RT-11 Pocket Guide
RT-11 Mini-Reference Manual
- - - - -
I am asking $800.00 for the lot. It cost me about that, probably more to acquire it piece-by-piece and assemble it into a working system.
smp
- - -
Stephen Pereira
Bedford, NH 03110
KB1SXE
I have quite a few Motorola Microsystems Exorciser boards including this
6800 single board computer for which I am lacking any documentation.
I've seen a brochure in Al's collection on Bitsavers but haven't found
any details that might discuss jumper settings or even better,
a schematic.
Wondering if anyone would have a user manual or other detailed docs for
this board?
M68MM01A2 -- has 6800 CPU, 6875 1.0 MHz clock generator, 6850 ACIA and
MC14411 baud rate clock, (4) EPROM/ROM sockets and (2) 6821 PIA sockets
with the 86-pin Exorciser edge connector.
I'm interested in seeing if I can minimally modify it to have a similar
memory map to the Altair 680 so that the Altair's PROM monitor could
run on it.
Thanks!
Chris
--
Chris Elmquist
> From: Grant Taylor <cctalk at gtaylor.tnetconsulting.net>
>
> I wince at the idea of running with QIC tape. But my experience is with
> QIC-80 tapes of the '90s which were so unreliable as to be in the same
> category as AOL floppy disks during the late '90s around the transition
> to CD-ROMs. As in I would trust an AOL floppy disk to better hold my
> data for a week than I would a QIC-80 tape to hold data for a month,
> much less a year. ...and I didn't even trust an AOL floppy to go from
> computer to computer for 5 minutes. -- Talk about a race to the bottom
> for quality.
I wish I'd kept some. I had some AOL CDs from slightly later that made decent coasters for decades. Although I guess with the shutter, the floppy wouldn't really have made a very good coaster.
Adam
Is anyone familiar with the IBM 6731 Diskette Module from around 1984 which
gave the IBM Electronic 85 and 95 Selectric Typewriters the ability to store
created documents to a 5.25" floppy diskette?
There was also a 5.25" diskette which was nicknamed "IPL" for "initial
program load", and an interface board which was installed into the
typewriter and was referred to as the "IBM Typewriter Modularity Option".
I do not have any images of the IBM 6731, but I do have an image capture
>from the installation and operations manual, posted here:
https://www.dropbox.com/s/us8aely530s8p3a/6731diskettemodule.jpg?dl=0
You do not need a Dropbox account to view the image. Simply click on the X
of the login pop up and it will disappear.
Unfortunately, the only copy of this product manual I ever found was on
eBay. I purchased it last month, paid USPS priority mail shipping with
tracking and the post office lost it. :/
Thanks
Don Resor
Is anyone familiar with the IBM 6731 Diskette Module from around 1984 which
gave the IBM Electronic 85 and 95 Selectric Typewriters the ability to store
created documents to a 5.25" floppy diskette?
There was also a 5.25" diskette which was nicknamed "IPL" for "initial
program load", and an interface board which was installed into the
typewriter and was referred to as the "IBM Typewriter Modularity Option".
I do not have any images of the IBM 6731, but I do have an image capture
>from the installation and operations manual, posted here:
https://www.dropbox.com/s/us8aely530s8p3a/6731diskettemodule.jpg?dl=0
You do not need a Dropbox account to view the image. Simply click on the X
of the login pop up and it will disappear.
Unfortunately, the only copy of this product manual I ever found was on
eBay. I purchased it last month, paid USPS priority mail shipping with
tracking and the post office lost it. :/
Thanks
Don Resor
Looking for CONAR CCTV? TV camera CONAR WERE KITS FROM NATIONAL RADIO COMPANY want books parts assembled units whole units? broken units-- I lust for one in the box un-assembled too! anything anything anything? related? toi this? camera? collecting up stories and folklore from others that may have? built one, owned one or? even just lusted? for? one!reply using the? following? ??SMECC CONAR TV CAMERA HISTORY PROJECT?? ? ?as? email reply? title? and? send? to?couryhouse at aol.comdrop me a line off list? with? first? word? CONAR? in subj. line? thx....Thanks in advance and stay well....Ed Sharpe? Archivist? for? SMECC