Re: cctalk Digest, Vol 89, Issue 21

[Josh Dersch via cctalk]

On Tue, Feb 22, 2022 at 3:29 PM Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

>
> On 22/02/2022 23:16, Glen Slick via cctalk wrote:
> > On Tue, Feb 22, 2022 at 2:20 PM Rod Smallwood via cctalk
> >  wrote:
> >> I'm sure that will work. Unfortunatly dd is a linux command.
> >>
> >> I only have windows PC's.
> >>
> > You never answered if you have a SCSI controller in your PC, or have
> > the ability to add a SCSI controller to your PC. If you don't, the
> > whole discussion of using 'dd' or equivalent is moo.
> >
> >
> >> simH is highly complex and needs a lot of setup. ( I know - I tried -
> >> total nightmare)
> >>
> > If you think setting up and using SIMH is highly complex, wait until
> > you find out how complex setting up and using real PDP-11 hardware is.
> >
> >
> >> It does not have support for the CMD CDD 220 SCSI controller and a
> RH-18A
> >>
> > Huh? SIMH emulates MSCP controllers and attached disks of arbitrary
> > size just fine.
>
> PDP hardware setup ? Well I worked for digital between 1975 and 1985.
>

Then you should be able to make SIMH work, no problem.

- Josh


>
> R
>
>
>

Re: VAX9000 unearthed

[Josh Dersch via cctalk]

On Fri, Feb 18, 2022 at 6:55 AM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
>
>
>
> Speaking of vector processors: there's a very obscure DEC processor, the
> DEC MPP.  I remember seeing the processor architecture document when it was
> being designed, not sure why.  It's a very-RISC machine, just a few
> instructions, but lots of cores especially for that time -- 256?  More?
> Recently I saw it mentioned in some documents, apparently it did get
> produced and shipped, perhaps only in small numbers.  I wonder if any have
> been preserved.


There was one listed on eBay for an obscene (like $500k?) price for quite
awhile, don't see it listed right now though.  Somehow I doubt it sold.
But at least there's one out there, somewhere...

- Josh



> As far as I know there is no family connection between that machine and
> anything else DEC did before or since.
>
> paul
>
>
>

Re: HP 2100S Power Supply Disassembly Tips

[Josh Dersch via cctalk]

No, I didn't.  I'm going to have to devote a fair amount of time to a
careful disassembly with copious notes and it's not something I can commit
to right now, so it's reassembled and back on the shelf for the time
being.  I'm used to HP gear being a bit more user-serviceable, but I guess
they did have a ton of stuff to cram into this supply and not a lot of
space to put it in.

- Josh

On Mon, Feb 14, 2022 at 3:27 AM  wrote:

> Josh:  Did you figure out a safe PS disassembly procedure?  If so, what
> and how did it go?
>
> -Original Message-
> From: cctalk  On Behalf Of Josh Dersch via
> cctalk
> Sent: Tuesday, February 1, 2022 1:49 AM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk@classiccmp.org>
> Subject: HP 2100S Power Supply Disassembly Tips
>
> 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
>
>

HP 2100S Power Supply Disassembly Tips

[Josh Dersch via cctalk]

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

Re: VAX 780 on eBay

[Josh Dersch via cctalk]

On Sun, Jan 9, 2022 at 2:56 AM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > 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).
>

As others have mentioned, power is one concern, but my guess is this:

No blinkenlights.  It's not exciting looking.  This tracks for PDP-11s (and
8's!) as well.  No one pays big money for 11/04, 11/34, 11/44 or LSI-11
systems (though prices are creeping up like everything else) but 11/05,
11/40, 11/70, etc. sell for huge amounts every time.  There's an 11/70
front panel at over $500 on eBay right now with two days left, it'll
probably sell for $2500.

- Josh



>
>   Noel
>
>

Re: VAX 780 on eBay

[Josh Dersch via cctalk]

On Sat, Jan 1, 2022 at 12:47 PM Guy Dunphy via cctalk 
wrote:

> At 07:50 PM 1/01/2022 +, you wrote:
> >>
> >True.  But if you're trying to get > $5000 for something, it doesn't seem
> unreasonable to suggest that investing a bit in getting an extension cord
> run to the location of the machine would be a good idea.  The absence of
> that effort makes me wonder if the owner knows what the outcome of such a
> test would be and doesn't want to have to report it.
> >>
> >
> >But what would that accomplish? I think testing something like this
> requires a lot more effort than plugging it in and hitting the circuit
> breaker. To test this to see if some ODT comes up probably requires quite a
> lot of effort (locate a terminal/pc, wire it up, figure out where to plug
> it into the 780, etc. If this guy is a bulk dealer I would be surprised if
> he has the knowledge to do anything more than a power test which, again,
> would not be very useful and could even be detrimental.
>
>
> Exactly. The machine has a 3-phase 208/240V plug, they don't have such an
> outlet. Their efforts stop right there.
>
> But you're all focussed on that, and missing another important detail. The
> machine has a liquid cooling system.
> Some of the hoses look like they are Tygon, in the age-decayed brittle
> stage. Touch them and they crumble away.
> Running the machine without cooling would utterly wreck it. Even if they
> solved the mains power problem,
> they would be very unwise to actually power it up.
>

For clarification -- the 11/780 is not liquid cooled.  The seller mixed up
some photos between the TU77 listing and the 11/780 listing (the TU77
listing has photos of the 11/780's backplane in it just to make things more
fun).  Agreed on all other counts, though, powering this thing up blindly
is a dumb idea.

- Josh

Re: VAX 780 on eBay

[Josh Dersch via cctalk]

On Sat, Jan 1, 2022 at 11:55 AM W2HX via cctalk 
wrote:

> >
> True.  But if you're trying to get > $5000 for something, it doesn't seem
> unreasonable to suggest that investing a bit in getting an extension cord
> run to the location of the machine would be a good idea.  The absence of
> that effort makes me wonder if the owner knows what the outcome of such a
> test would be and doesn't want to have to report it.
> >
>
> But what would that accomplish? I think testing something like this
> requires a lot more effort than plugging it in and hitting the circuit
> breaker. To test this to see if some ODT comes up probably requires quite a
> lot of effort (locate a terminal/pc, wire it up, figure out where to plug
> it into the 780, etc. If this guy is a bulk dealer I would be surprised if
> he has the knowledge to do anything more than a power test which, again,
> would not be very useful and could even be detrimental.
>

Right.  I'll pay significantly less for an 11/780 that some random scrapper
has powered up.

- Josh



>
>
> 73 Eugene W2HX
> Subscribe to my Youtube Channel:
> https://www.youtube.com/c/w2hx-channel/videos
>
>
>
>

ISO: DEC PDP-8 Data Multiplexer (DM01, etc.)

[Josh Dersch via cctalk]

Hey all --

Got the TC01 working the other night, after a couple weeks of debugging
(*).  I'd like to be able to have both it and the RF08 that I'm working on
connected to the 8/I and running at the same time, so I'm looking for a
DM01 Data Multiplexer.  If anyone has any leads, do let me know.

Thanks as always,
- Josh

(*) Total TC01 fault count (so far):
- Bad transistor in TU55 motor brake control (W040)
- Bad jumper solder joints in TU55 (W990)
- Timing of UTS and U+M one-shots (R303) way out of adjustment (U+M
one-shot was at 2 seconds or so...)
- Bad tape data relay (G851)
- Bad IOT decoder transistor (W103)
- Missing Diode (W113) and weak diode in Write enable selection logic
- Timing of write clock way, way out of adjustment (90Khz vs. 125Khz
expected.)
- 24 dead maintenance panel bulbs
- 2 dead TU55 bulbs (yet to be replaced)

Re: Source for DEC TC01 (and similar) bulbs?

[Josh Dersch via cctalk]

On Mon, Dec 6, 2021 at 7:39 AM Michael Thompson <
michael.99.thomp...@gmail.com> wrote:

>
>
> On Sun, Dec 5, 2021 at 11:46 PM Josh Dersch  wrote:
>
>> I swapped boards around in the datapath for these bits on the TC01 side
>> last night and the problem doesn't move.  On a whim I put my thumb on the
>> tape as it passes over the head and it seems to affect the glitchiness of
>> the data, at times making it appear to go away entirely.  Doesn't appear to
>> be a tape tension problem -- it seems adequate and putting my thumb on the
>> supply reel to increase tension a bit does not have the same effect.  This
>> would seem to point to the TU55 being the issue, and quite possibly the
>> heads.  I haven't had time today to look at the signals coming off the
>> heads but I plan to soon.
>>
>> Thanks for the help!
>> - Josh
>>
>
> I would measure the resistance of the head coils at the relay board
> connector. Hopefully they all measure about the same. Figure 2-2 in the
> maintenance manual shows how the MARK and DATA tracks are wired, and the
> extra connection available for the TIMING track. We found a head on the
> PDP-9 where the +D0 connection was open.
>

Looks like I lucked out.  Testing the head signals at the backplane on the
TU55 revealed that pin BD1 was a flat line at about -0.5V.  Turned out to
be a bad relay on the G851 relay board.  (There was also some gnarly black
gunk on the pins on the head connector which somehow wasn't the
problem...)  I don't have any spare relays, but I swapped a G851 in from my
TU56 and the glitches have gone away.  If anyone has any spare relays for
these, or a G851 lying around, let me know.

The Basic Search diagnostic still isn't finding any blocks on the tape, and
I can tell by the lights on the panel that the LPB register isn't doing
much of anything, so I have some more debugging to do.  But I'm really glad
that the TU55 is OK.  Thanks for the help!

- Josh



>
> --
> Michael Thompson
>

Re: Source for DEC TC01 (and similar) bulbs?

[Josh Dersch via cctalk]

On Sun, Dec 5, 2021 at 4:39 PM Michael Thompson via cctalk <
cctalk@classiccmp.org> wrote:

> >
> >
> > From: Josh Dersch 
> > Subject: Source for DEC TC01 (and similar) bulbs?
> >
> > The Search Scope loop diagnostic shows block numbers going by in both
> > directions so a lot of the drive and controller are working, but there's
> > some glitchiness in bits 2, 5, 8, and 11 of the data so I need to trace
> > that down; I hope it's not the tape head.
> >
> > - Josh
> >
>
>  So what do bits 2, 5, 8, & 11 have in common? All bits come from the same
> track on the tape head, and share some of the path to the Data Buffer.
>

Yep!


>
> If you wrote this tape on this system, I would try reading a tape that was
> written on another machine to make sure that the problem didn't originate
> with writing.
>

The TC01 isn't quite up for writing things yet (well, I haven't tried, but
I suspect it wouldn't go well).  The tapes I've been trying are known-good
DECtapes I have, that I've read on my 8/m with its TD8E without issues.


>
> Check for a bad connection where the tape head cable connects to the G851
> module in the TU55, where the G851 plugs into the TU55 backplane, and where
> the data cable plugs into the TU55 backplane, and possibly the K2 relay on
> the G851.
>
> In the TC01 you could swap the G888 module in slot C22, the S205 module in
> slot D05, the S205 module in slot E06, the S603 module in slot C02, or the
> R123 module in slot E08, with another one to see if the glitch moves to
> another bit.
>

I swapped boards around in the datapath for these bits on the TC01 side
last night and the problem doesn't move.  On a whim I put my thumb on the
tape as it passes over the head and it seems to affect the glitchiness of
the data, at times making it appear to go away entirely.  Doesn't appear to
be a tape tension problem -- it seems adequate and putting my thumb on the
supply reel to increase tension a bit does not have the same effect.  This
would seem to point to the TU55 being the issue, and quite possibly the
heads.  I haven't had time today to look at the signals coming off the
heads but I plan to soon.

Thanks for the help!
- Josh



>
> --
> Michael Thompson
>

Re: RK11-C indicator panel inlays?

[Josh Dersch via cctalk]

On Sun, Dec 5, 2021 at 12:24 PM Ethan Dicks via cctalk <
cctalk@classiccmp.org> wrote:

> On Sun, Dec 5, 2021 at 2:12 PM Noel Chiappa via cctalk
>  wrote:
>
> > Anyway, if anyone is interested, the next step would be to find out who
> all
> > wants an RK11-C inlay, and work out _exactly_ what would be printed on
> it.
>
> Put me down for one.  I've had this RK11-C for a long time and haven't
> done anything with it.


Ditto me.  I snagged an RK11-C earlier this year and my plan is to get to
restoring it sometime next year.

- Josh



> I have always planned to put it back on the
> 11/20 it came with, but first I need to get the 11/20 going so that's
> pushed down the RK11-C.  This would be really cool as a debugging tool
> more than just as amazing lights.
>
> -ethan
>
> P.S. - not to derail things, but definitely loop me in on the (future)
> thread for making reproductions.  I have access to some tools that
> might make parts of it easier.
>

Re: Women of Computing

[Josh Dersch via cctalk]

On Sun, Dec 5, 2021 at 8:57 AM Chris Long via cctalk 
wrote:

> The fact I don’t think it is necessary for a Lego set specifically
> endorsing the role of women in computing is unpleasant or mean spirited?
>

That's not what your initial response said, and you know it.  You can
backpedal all you want.  Rather than starting an actual discussion of the
merits of the project you replied flippantly, using the word "woke" to
completely dismiss the project, with all the weight that word connotes.


>
> Get a life Liam. I simply expressed my view.
>
> Are we really at a state on this list where when someone posts mentioning
> something, that anyone who expresses any alternative view is behaving
> unacceptably?
>

Nope.  You know this, too.


>
> Talk about snowflakes.
>

There you go again.
- Josh


> -Original Message-
> From: cctalk  On Behalf Of Liam Proven via
> cctalk
> Sent: 05 December 2021 15:17
> To: Doc Shipley ; General Discussion: On-Topic and
> Off-Topic Posts 
> Subject: Re: Women of Computing
>
> On Sun, 5 Dec 2021 at 16:09, Doc Shipley via cctalk 
> wrote:
> >
> > On 12/4/21 12:37, Josh Dersch via cctalk wrote:
> > >
> > > OK, Boomer.
> > >
> > There's really no call to be nasty about it.
> >
> > To those of us who are baby boomers, that usage is extremely offensive.
>
> I suspect that was the plan.
>
> Chris Long's email was nasty, unpleasant and a mean-spirited and
> unpleasant thing to say. The fact that they felt the need to say it on a
> public forum indicates either that they do not care what other people feel,
> or that they wanted to cause offence.
>
> When someone is so insensitive that they do not understand that their
> words can hurt others, then sometimes, an effective way to show to them
> that words can be hurtful and that they shouldn't say mean things, is to
> say something that is hurtful to them.
>
> This can illustrate to people who do not normally care about others'
> feelings that they do not like it when their own feelings are hurt.
>
> It is, sadly, a common attribute of a certain age group, especially of old
> white straight men, to give little regard to others' feelings like this.
> They typically consider a waste of time any kind of affirmative action that
> helps, boosts, or engages with people who are not old, white, straight and
> men.
>
> This is a bad way to behave. Nobody should act like that. It violates
> Wheaton's Law, which is a basic principle of how to be a civilised human
> being.
>
> "OK, Boomer" is just a succinct and clear way of saying "you are an
> unpleasant old man and we do not need to listen to your useless hurtful
> opinions."
>
> If that sounds like you, then my advice to you is not to complain about
> it, but to engage with it, and learn how not to be such a person, and then
> go and teach other such folk how to be better people.
>
> If it doesn't sound like you, then you should not be bothered by it.
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420)
> 702-829-053
>
>

Source for DEC TC01 (and similar) bulbs?

[Josh Dersch via cctalk]

Anyone sitting on a pile of these or know where to find some?  These were
originally Dialco 507-3917 or Drake 11-507 based on what was installed in
mine.  24V, 40mA, white.

A total of 23 bulbs were dead on my TC01's panel.  I've installed a pile of
electrically/physically compatible bulbs that I happened to have, but
they're yellow/orange and have a different visual design (the yellow lens
sticks out 1/8" or so, whereas the orginals were flush).  I'm honestly fine
with using them but it'd be nice to have something that looks original.

And a small progress update:  Found that the IOT decode for READ STATUS B
wasn't working, which is done on the W103 decoder at E/F19.  With that
resolved the diagnostics are behaving much more rationally.  This took me
much too long to trace down, but I learned a lot about how the controller
works and found a fun (but ultimately harmless) bug in the Basic Exerciser
diagnostic that threw me off for a couple of days...

The Search Scope loop diagnostic shows block numbers going by in both
directions so a lot of the drive and controller are working, but there's
some glitchiness in bits 2, 5, 8, and 11 of the data so I need to trace
that down; I hope it's not the tape head.

- Josh

Re: Women of Computing

[Josh Dersch via cctalk]

On Sat, Dec 4, 2021 at 10:20 AM Chris Long via cctalk 
wrote:

> Great.not.
>
> Why do we need woke Lego?
>

OK, Boomer.
- Josh


> -Original Message-
> From: cctalk  On Behalf Of Zane Healy via
> cctalk
> Sent: 03 December 2021 17:35
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk@classiccmp.org>
> Subject: Women of Computing
>
> I really want to see this set produced, especially for the “Ada Lovelace”
> and “Admiral Hopper” portions of the set.
>
>
> https://ideas.lego.com/blogs/a4ae09b6-0d4c-4307-9da8-3ee9f3d368d6/post/f39b7001-bf76-46ba-9d61-cb586f1c7a7d
>
> https://ideas.lego.com/projects/3bf5b46c-6c87-4a2d-a2e1-d31ed0e2739e
>
> Zane
>
>
>
>

Re: Unrecognized DEC Power Supply in PDP-11/44 Configuration

[Josh Dersch via cctalk]

On Thu, Dec 2, 2021 at 6:29 AM pbirkel--- via cctalk 
wrote:

> Does anyone recognize the (presumably) DEC power supply on the front half
> of
> the rack-bottom in the 11/44 listing at:
>
>
>
> https://www.ebay.com/itm/363640137050
>
>
>
> Blurry photo, but it looks like there are a 4x3, a 3x3, and a 3x5 Molex
> connector, and two brown mini-modules protruding from the right side.
>
>
>
> If so, then what purpose did it likely serve?
>

It's not a DEC power supply, it's a Fujitsu power supply, likely for an
M2284 SMD drive.  Probably went in the empty slot you mention below.

- Josh



>
>
>
> It appears that the 6U immediately below the 11/44 was likely occupied by
> an
> RX02 given the presence of an M8256 in the 11/44 backplane (and skinny
> mounting rails, although I thought those were usually at the bottom of the
> RX02), and that included its own power supply (which wasn't very beefy
> either, nor did it need to be).
>
>
>
> What went into the 6U immediately above the power supply is unclear; there
> is a HEX Wespercorp TC130 Tape Controller as well as three unknown QUAD
> modules in the 11/44 backplane.  Perhaps there was a horizontal autoload
> tape drive mounted there that required a separate power supply?
>
>
>
> Curious!
>
> paul
>
>

Re: Looking for tips debugging DEC TC01 controller

[Josh Dersch via cctalk]

On Tue, Nov 30, 2021 at 1:57 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Nov 23, 2021, at 3:17 PM, Josh Dersch via cctalk <
> cctalk@classiccmp.org> wrote:
> > I picked up a TC01 in trade (for a TC08) a couple of weeks back and this
> > past weekend I got it hooked up and powered up with my PDP-8/I + TU55
> > transport.  I've been debugging it and have solved a couple of issues but
> > the current one has me stumped and I'm looking for advice, hoping I
> > overlooked something obvious...
>
> Any updates here, Josh?  I’m not familiar enough with 8’s or their
> peripherals to offer any relevant suggestions, but I’m curious to hear what
> you find and how you crack it!
>

After poking at it awhile, a friend of mine pointed out that the W1 flip
flop is set up so it will only toggle once, after the first "1" bit comes
in from W2.  This is actually pointed out in the TC01 maintenance manual
but I had managed to overlook it.  I'm still not entirely sure why it
behaves this way (I guess so it only gates mark blocks after the first real
data goes through the WINDOW register?) but it's good to know it's working
properly.

Tracing further through the circuitry reveals that the first SEARCH
operation executed by the "Search Find All Blocks" diagnostic isn't
executing properly -- it sets the GO bit momentarily and all the command
bits seem to be making it to the controller, but before the drive begins
forward movement "GO" goes low and after that nothing happens; the
diagnostic halts after waiting for an interrupt for about 30 seconds.
Regular MOVE operations appear to work fine.  I've got a ton of signals to
dig through so I'm not sure what's going on yet.  Think I may need to get
the Logic Analyzer out for this one.

- Josh



>
> —FritzM.
>
>
>

Re: PDP-11/70 Boards

[Josh Dersch via cctalk]

On Mon, Nov 29, 2021 at 1:06 PM Ethan Dicks via cctalk <
cctalk@classiccmp.org> wrote:

> On Mon, Nov 29, 2021 at 3:19 PM Henk Gooijen via cctalk
>  wrote:
> > I think the FP11 boards are not essential for the 11/70
> > They only add hardware FP support.
>
> Not essential for many uses, but I'm pretty sure UNIX is unhappy
> without them.  If you are going to run RSTS/E or RT-11, should be just
> fine either way.
>

Depends on the UNIX.  Ultrix works fine, and the latest patchlevel of
2.11BSD has floating point simulation that works fine.

(I'm running my 11/70 sans floating point hardware at the moment, I'd still
like to find a boardset one of these days, though.  Floating point
emulation is slow!)


>
> > However, I think that the cache boards are essential.
> > Not sure the 11/70 will work without them.
>
> Agreed.  I think those _are_ mandatory.
>

Yes, the cache is an integral part of the memory system on the 11/70.

- Josh



> Cheers,
>
> -ethan
>

Re: Micro Technology Board Info

[Josh Dersch via cctalk]

On Sat, Nov 27, 2021 at 2:39 PM Josh Dersch  wrote:

> On Sat, Nov 27, 2021 at 12:53 PM Jerry Wright via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Have this board here, but can't find any Info on it.
>> Says Neptune board on the silkscreen, tag say model MSD138 T devDates are
>> about 1990 to 1992.
>> https://www.dropbox.com/s/uu8x7bc5a08jw90/IMG_2200.jpg?dl=0
>> https://www.dropbox.com/s/e8z542sdnusjpqa/IMG_2201.jpg?dl=0
>> https://www.dropbox.com/s/xql6w5zhiismbel/IMG_2199.jpg?dl=0
>
>
> I believe that's an SDI to ESDI bridge.  I have an enclosure marked "MTI
> MDI 240" on it that contains two of those, along with four ESDI disks, with
> SDI connectors on the rear.
>
> - Josh
>

Here's a pic of the boards in mine.  Looks to be identical:
https://1drv.ms/u/s!Aqb36sqnCIfMqKN2zHcNM6MUyS0b8Q

- Josh

Re: Micro Technology Board Info

[Josh Dersch via cctalk]

On Sat, Nov 27, 2021 at 12:53 PM Jerry Wright via cctalk <
cctalk@classiccmp.org> wrote:

> Have this board here, but can't find any Info on it.
> Says Neptune board on the silkscreen, tag say model MSD138 T devDates are
> about 1990 to 1992.
> https://www.dropbox.com/s/uu8x7bc5a08jw90/IMG_2200.jpg?dl=0
> https://www.dropbox.com/s/e8z542sdnusjpqa/IMG_2201.jpg?dl=0
> https://www.dropbox.com/s/xql6w5zhiismbel/IMG_2199.jpg?dl=0


I believe that's an SDI to ESDI bridge.  I have an enclosure marked "MTI
MDI 240" on it that contains two of those, along with four ESDI disks, with
SDI connectors on the rear.

- Josh



>
>
> - Jerry
>

Looking for tips debugging DEC TC01 controller

[Josh Dersch via cctalk]

Hey all --

I picked up a TC01 in trade (for a TC08) a couple of weeks back and this
past weekend I got it hooked up and powered up with my PDP-8/I + TU55
transport.  I've been debugging it and have solved a couple of issues but
the current one has me stumped and I'm looking for advice, hoping I
overlooked something obvious.

At this point the PDP-8/I can talk to the TC01 and use it to control the
TU55 without issue.  I've mostly been using MAINDEC-08-D3BB to exercise the
hardware (see:
http://svn.so-much-stuff.com/svn/trunk/pdp8/src/dec/maindec-08-d3b/maindec-08-d3bb-d.pdf)
and issuing FWD/BACK commands via the "Basic Motion" routine the tape runs
from one end of the tape to the other, stopping at the endzones correctly.
The tape comes up to speed properly, the COUNTER register increments, and
in general the various status lights on the panel do what I expect them to
do.

The root symptom I'm seeing now is that DECtape operations (like SEARCH)
don't complete, and I've traced this back to the MK BLK MK signal not
getting asserted.  This signal is generated by a large AND gate (see p. 112
of
http://bitsavers.trailing-edge.com/pdf/dec/dectape/tc01/DEC-08-I2AB-D_TC01_Jul69.pdf).
This gate ANDs together a pile of signals from the WINDOW register and the
counter, looking for a specific bit pattern on the mark tracks; this AND
gate is never satisfied because the WINDOW register's MSB (W1) is stuck
low.  On the scope it's a completely flat line, no glitches or anything
noticeable.

Despite my best efforts I cannot figure out why this is.  Here's what I've
looked at and what I've discovered thus far:

1) The inputs to the W1 flip-flop (pins U (clock) and V (data) look to be
correct -- U is identical to the TP1 signal being passed to all the other
flip-flops in the chain, and V is identical to the data coming out of W2 --
levels all look fine.

2) The outputs of W1 (pins T and S) are not being pulled up or down by
anything external. I've gone so far as to completely disconnect T and S
from the backplane (with some tape over the card fingers) and the outputs
are still a flat line.

3) The output of pin T goes to -3V when 0->WINDOW is de-asserted (when tape
is in motion), returns to 0V when 0->WINDOW is asserted after the tape
stops.  (S is the inverse of this, as expected.)  (As an aside, the
schematic drawing suggests that 0->WINDOW ought to be a pulse given the
arrow symbol; this does not appear to be the case.  Other flip flops in the
chain seem to behave properly, regardless...)

4) The backplane connection to the R203 flip-chip that the W1 flip-flop is
on is fine.  I've beeped this out and there's no significant resistance
between the backplane pins and the connection to the card in the slot.

5) W1 is not affected by the state of the two other flip flops on the R203
(also tested by disconnecting all pins other than power/gnd and pins
R/S/T/U/V with tape).

6) Swapping in a different, working R203 shows no change in behavior.

6) Sometimes, randomly, W1 starts working.  Last night I noticed that the
solder side of R203 was rubbing against the top of the "flip chip" packages
on the R107 next to it and even though those shouldn't be conductive, I
stuck a piece of cardstock between the two.  W1 started working!  I tested
things for about a half hour in this state (interrupts were still not
occurring, much to my annoyance) and this morning I powered it up and it
was still working.  Pulled the cardstock out and W1 stopped working; this
would seem to causation.  Put the cardstock back in... still won't work.
Backplane connections all test out fine (see (4) above).  Put the R203 on
an extender (to completely avoid interference with neighboring cards) and
still no go.  Possibly the insertion of the cardstock flexed the board or
the connection with the backplane slot ever so slightly to make things work
but if so I've been unable to replicate it.

All of this still sounds like a bad connection somewhere (backplane, cold
solder joint, broken trace) but the evidence seems to be against it
(checked, double-checked, triple-checked backplane, swapped R203s around,
etc...)

Anyone have suggestions?  I'm going to start looking at things on the board
itself (which is going to be a pain given how things are currently arranged
in the chassis) but curious if I've missed anything here...

- Josh

For Sale, Seattle area: Data General MV/7800 + drives, docs

[Josh Dersch via cctalk]

Hi all --

I'm doing a bit of cleanup to free up some space and I'd like to try to
find a new home for my MV/7800.  It's a really cool system that I just
haven't had time to spend a lot of time with, and unfortunately it seems
unlikely I will anytime soon.

The power supply in the CPU has been repaired.  There are two large 5236
drives (I believe they have 14" platters, and they weigh about 150lbs
apiece) as well, unfortunately I do not have the cabling for them but I
don't think it'll be too hard to recreate it.  The system appears to be
complete with CPU, memory, and disk/tape controllers but apart from getting
the power supply going I haven't done anything else to restore it.

If anyone's interested, drop me a line.  I'd much prefer local pickup but I
could be convinced to put this stuff on a pallet if you want to arrange
freighting.

Thanks,
Josh

Re: ISO: GE Terminet 300 knowledge

[Josh Dersch via cctalk]

On Sat, Oct 30, 2021 at 11:25 PM Tony Duell  wrote:

> On Sun, Oct 31, 2021 at 6:15 AM Josh Dersch via cctalk
>  wrote:
> >
> > Hey all --
> >
> > I picked up a GE Terminet 300 which appears to be mostly functional, but
> is
> > in need of alignment --  it's printing fairly smudged garbage with a few
> > recognizable characters intermixed.  Character positioning (horizontal)
> > seems to be fairly irregular, for the characters that print clearly.
> >
> > The unit has suffered some knocks in its life and it's clear the
> photocell
> > board has come slightly loose, which I'm sure is not unrelated, so I'm
> > studying the service docs to get a better idea what's going on.  There's
> an
> > alignment gauge which I could reproduce if I had any idea what it's specs
> > are.  The service docs are a bit vague and the photocell assembly is a
> bit
> > difficult to see, buried beneath the print band on the left hand side.
> >
> > Anyone out there have any experience with these?  Any wisdom to impart
> here?
>
> I think this was badged 'ICL' in the UK, I have a couple (118
> characters/line KSR and 75 charaters/line RO) but it's been several
> years since I worked on them.
>
> From what I remember the photocell unit is the main timing sensor. It
> detects the bottom tabs of the print fingers, the start finger of each
> set has a wider tab spot-welded to it (and thus that finger can't be
> removed from the belt) which gives a wider pulse that's detected by
> the electronics.
>

Yes, this matches what the service docs explain, sounds like the same
machine.


>
> If the photocell unit is not in the right position laterally but still
> gives good timing pulses, the thing will work but won't hit the
> fingers cleanly. You should still get the right characters, or perhaps
> the one before or after on the belt if it's way out of position. But
> if it's not producing clean pulses all the time then the thing may
> print random characters.
>
> A missing finger is bad news for that reason, The missing timing pulse
> may well confuse the electronics.
>

I should have been more clear -- only the top of the finger is missing, the
bottom is still present, so it should in theory be generating proper pulses.

I should see if I can pull the assembly out and clean it, I suppose if the
optical sensors are dirty it'd be a problem.

- Josh


>
> -tony
>
>
>
> >
> > Also, anyone have any spare print fingers?  My print band's missing one
> (a
> > "9") and I suppose it wouldn't be a terrible idea to have a few extras
> just
> > in case...
> >
> > Thanks,
> > - Josh
>

ISO: GE Terminet 300 knowledge

[Josh Dersch via cctalk]

Hey all --

I picked up a GE Terminet 300 which appears to be mostly functional, but is
in need of alignment --  it's printing fairly smudged garbage with a few
recognizable characters intermixed.  Character positioning (horizontal)
seems to be fairly irregular, for the characters that print clearly.

The unit has suffered some knocks in its life and it's clear the photocell
board has come slightly loose, which I'm sure is not unrelated, so I'm
studying the service docs to get a better idea what's going on.  There's an
alignment gauge which I could reproduce if I had any idea what it's specs
are.  The service docs are a bit vague and the photocell assembly is a bit
difficult to see, buried beneath the print band on the left hand side.

Anyone out there have any experience with these?  Any wisdom to impart here?

Also, anyone have any spare print fingers?  My print band's missing one (a
"9") and I suppose it wouldn't be a terrible idea to have a few extras just
in case...

Thanks,
- Josh

Re: Looking for info on memory

[Josh Dersch via cctalk]

On Sat, Oct 23, 2021 at 10:30 AM Josh Dersch  wrote:

>
>
> On Sat, Oct 23, 2021 at 10:12 AM Nigel Johnson Ham via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> It is not possible to get ODT running without bank 0 memory.  All I get
>> is output of 173000 and the no ability to input.
>>
>
> How is your CPU board configured?  Based on the above, it sounds like it's
> set up to jump to a ROM bootstrap at power-up (at 173000) and I'm guessing
> given your current configuration that there isn't one.  Without memory
> present/functional, this may be confusing things further.  There are
> jumpers on the 11/23 CPU to select what the CPU does at power-up (see:
> https://gunkies.org/wiki/KDJ11-A_CPU).  Try setting it to drop directly
> into ODT instead.
>

Sorry, just realized I pasted a link for the 11/73 CPU config (same basic
idea, though).  Try this instead:
http://www.willsworks.net/pdp-11/boards#KDF11-BA.

- Josh


>
> - Josh
>
>

Re: Looking for info on memory

[Josh Dersch via cctalk]

On Sat, Oct 23, 2021 at 10:12 AM Nigel Johnson Ham via cctalk <
cctalk@classiccmp.org> wrote:

> It is not possible to get ODT running without bank 0 memory.  All I get
> is output of 173000 and the no ability to input.
>

How is your CPU board configured?  Based on the above, it sounds like it's
set up to jump to a ROM bootstrap at power-up (at 173000) and I'm guessing
given your current configuration that there isn't one.  Without memory
present/functional, this may be confusing things further.  There are
jumpers on the 11/23 CPU to select what the CPU does at power-up (see:
https://gunkies.org/wiki/KDJ11-A_CPU).  Try setting it to drop directly
into ODT instead.

- Josh

Re: ISO M100, M102, M633 flip chips for DEC TC08N controller

[Josh Dersch via cctalk]

On Fri, Oct 1, 2021 at 1:09 AM Joshua Rice via cctalk 
wrote:

>
>
> -- Original Message --
> From: "Josh Dersch via cctech" 
> To: "General Discussion: On-Topic and Off-Topic Posts"
> 
> Sent: Friday, 1 Oct, 2021 At 08:33
> Subject: ISO M100, M102, M633 flip chips for DEC TC08N controller
> Hey all --
> I have a TC08 DECtape controller that I'd like to convert to a TC08N
> (the
> negibus version of the TC08). If I'm reading the documentation right,
> this
> involves swapping in a few flip chips -- M100 for the installed M101,
> M102
> for M103, and M633 for M623.
> If anyone has any of these, please drop me a line. Curious also if
> anyone
> out there has done this conversion and can comment on whether my
> assessment
> is correct...
> Thanks!
> - Josh
>
> I might be preaching to the choir here, but if you can't find originals,
> this website is an absolute goldmine for flip-chip schematics. If you
> can find the components (or modern equivalents) it might be worth making
> your own.
>
> https://so-much-stuff.com/pdp8/flipchip/Mxxx.htm
> 
>

Yep, Vince has made an awesome site with a lot of incredibly useful things,
and if I have to I'll build my own replacements, should be fun.  But if I
can find original parts, I'd much prefer to use them.

Thanks!
- Josh



>
> Josh Rice
>

ISO M100, M102, M633 flip chips for DEC TC08N controller

[Josh Dersch via cctalk]

Hey all --

I have a TC08 DECtape controller that I'd like to convert to a TC08N (the
negibus version of the TC08).  If I'm reading the documentation right, this
involves swapping in a few flip chips -- M100 for the installed M101, M102
for M103, and M633 for M623.

If anyone has any of these, please drop me a line.  Curious also if anyone
out there has done this conversion and can comment on whether my assessment
is correct...

Thanks!
- Josh

Re: PDP-11/73 boot issues

[Josh Dersch via cctalk]

On Tue, Sep 21, 2021 at 12:05 PM Aaron Jackson via cctalk <
cctalk@classiccmp.org> wrote:

> Hi all,
>
> My PDP-11/73 has started misbehaving after several years of being very
> stable. It is showing symptoms similar to when I've forgotten to enable
> the LTC in the past, except this time, it is enable.
>
> Power supply seems good - +5V, +12V, all seems there and appears to be
> stable. I've probed the LTC going onto the backplane and I'm getting
> 50Hz. It looks a tad noisy, not sure if this is a problem. I will see if
> I can get a picture of it, but it has very distinct rises and falls, so
> hopefully that's ok. Looks to be about 50% duty cycle.
>
> I've attempted several builds of the kernel, including the
> out-of-the-box build from 2.11BSD distribution. I've also compiled a
> shrunk down kernel without a bunch of devices I don't have, but it still
> fails to work. I am using a SCSI2SD so it's easy for me to copy images
> and test them in SIMH - they all boot fine in SIMH with a similar setup
> (mscp, tmscp, 11/73, 1MB-ish RAM).
>
> Does anyone have any ideas what might be causing this? I've run out of
> ideas unfortunately. I'll stick a dump of the boot below, with debug
> flag passed showing output from autoconfig.
>
> I've also tried it without the tmscp card - just CPU, RAM and Emulex
> UC07 in MSCP mode for scsi disk. I have tried it with less memory, and
> I've tried removing the halt jumper from the 11/73 board (W5 if I
> remember correctly)
>
> Cheers,
> Aaron
>
> -
> ^C
> BOOT>  DU 0
>
> 73Boot from ra(0,0,0) at 0172150
> : ra(0,0,0)unix -D
> Boot: bootdev=02400 bootcsr=0172150
>
> 2.11 BSD UNIX #116: Wed Dec 31 18:01:57 CST 1969
> r...@localhost.2bsd.com:/usr/src/sys/GENERIC
>
> ra0: Ver 5 mod 13
> ra0: RA81  size=1216601
>
> phys mem  = 1179648
>

This is an interesting amount of physical memory to report (1152K).  What
memory board(s) do you have installed?

Other than that, this output looks sane to me.  I'd suggest booting XXDP
and running CPU, memory diagnostics from there.

- Josh

Re: VAXstation 100 ROM image

[Josh Dersch via cctalk]

On Tue, Sep 21, 2021 at 10:43 AM Jonathan Stone via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On Tuesday, September 21, 2021, 10:17:33 AM PDT, Chris Zach via cctech <
> cct...@classiccmp.org> wrote:
>
>
> > How the hell did I miss *that*? Cool beans device, I've never heard of a
> > VS100. Was it in a Rainbow sized box or a Pro/350 box?
>
> If old memories serve, you'd also need the Unibus-to-Qbus converter. I
> recall a discussion between someone from, I think DEC UK Reading, asking
> about a DEC Unibus-to-Qbus converteer. The other person said DEC didn't
> have such a device. then Vaxstation-100 was mentinoed. I expect you could
> get it to work as a Qbus device with 18-bit addresssing.
>

No, there's no QBus involved here.  The M7452 "UNIBUS Window Module"
connects the VS100 to the VAX via a fiber-optic link.

(DEC did make a Unibus to Qbus adapter, the DW11-B, but it was unrelated to
the VS100)

- Josh

Re: VAXstation 100 ROM image

[Josh Dersch via cctalk]

On Tue, Sep 21, 2021 at 10:04 AM Zane Healy via cctalk <
cctalk@classiccmp.org> wrote:

> I’m rather wondering how I missed that Auction.  That’s the first time
> I’ve ever seen any photos of a VS100.  I believe it required a UNIBUS card
> to connect it to the VAX.
>

Yes, with a fiber optic link; here's a picture of the board (M7452) and
cabling:

https://1drv.ms/u/s!Aqb36sqnCIfMo_cMPAR0aeAPKAYXJg

And here's a pic of my VS100 running (connected to an 11/750 running
4.3BSD):

https://1drv.ms/u/s!Aqb36sqnCIfMo_cUO4EiMWOHZVk8yg

(Still trying to hunt down a VR100 monitor, in case anyone has one...)

- Josh



>
> Zane
>
>
> > On Sep 21, 2021, at 9:58 AM, Chris Zach via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > How the hell did I miss *that*? Cool beans device, I've never heard of a
> VS100. Was it in a Rainbow sized box or a Pro/350 box?
> >
> >
> > C
> >
> > On 9/21/2021 12:35 PM, Glen Slick via cctalk wrote:
> >> On Tue, Sep 21, 2021 at 9:10 AM Lars Brinkhoff via cctalk
> >>  wrote:
> >>> Hello,
> >>>
> >>> Does anyone have a (set of) ROM image(s) for the VAXstation 100?
> >>> It might be interesting to attempt an emulator.
> >> Did someone on the list buy this one? That was the only one that I
> >> have noticed for sale on eBay anytime recently.
> >>
> >> https://www.ebay.com/itm/294252478149
> >> Rare Dec Vaxstation 100 Prototype Digital VAX
> >> Ended: Jul 07, 2021
> >> Winning bid: US $256.00
>
>

Re: More cleaning out the Bob basement

[Josh Dersch via cctalk]

On Sun, Sep 19, 2021 at 1:39 PM Chris Zach via cctalk 
wrote:

> On 9/18/2021 10:04 PM, Toby Thain via cctalk wrote:
> > https://memegenerator.net/img/instances/64153952.jpg
>
> No problem with stopping the stupid wife stuff, but this is an important
> issue: Cleaning out basement hoards like this is *NOT* easy, and if you
> have one make plans now for when you die. It can happen sooner than you
> think due to accident/whatnot.
>
> On the positive side this is a bit of a time capsule and we *did* get
> all the Perq software and documentation out on the tapes. That was a
> serious win apparently.
>

I'm still working through the tapes and I've had decent success with them,
however if I may add to Chris's suggestions: don't leave tapes in a damp
basement for 20+ years, it makes them difficult to read.  All the more
frustrating when they contain what may be the only surviving copy of
various bits of software for an obscure workstation :).

- Josh

Re: HP-UX on 9000/200 series

[Josh Dersch via cctalk]

On Tue, Aug 31, 2021 at 8:09 PM Paul Berger via cctalk <
cctalk@classiccmp.org> wrote:

> I have a couple of those CPU cards too, and they should fit a a 9826 or
> 9836 as well, but looking at the pictures of that CPU card as posted on
> hpmuseum.net the part number of the processor on the card is a 12MHz
> 68000.  Since all the enhancements between 68000 and 68010 are internal
> and they have identical pinouts, it would seem at some point HP started
> putting 68010 processors on them. The ones I have with 68010 processors
> came out of a 4972A which is a network trace tool that is built around
> hardware similar to a 9920.  This processor card does have some memory
> management hardware on it, but it seems odd that they would build a
> processor with memory management and use a processor that cannot recover
> from a page fault, however is they have a 68010 installed it can handle
> page faults.  I don't know if this processor card can support 5.1 I
> don't think I tried it when I first stumbled onto the diskette images, I
> believe I only ever tried it on a 310 and found that it was hopelessly
> slow, so I moved onto a 380 with maxed out memory and a later version of
> HP-UX.  On the hpmuseum.net site they tried it on a 9817 and it did not
> work, which may suggest it will also be an issue for these processor
> cards with a 68010 on them.
>

I had a brief saga with this same issue a few years back, with my 9836CU.
There was some discussion on the list:

http://classiccmp.org/pipermail/cctalk/2017-November/035725.html

Long story short:  I tried a 68010 (and 68012) in the socket and while the
system was functional, it didn't magically give it the ability to boot
HP-UX 5.1, at least in my experience.  If you give it a try I'd love to
know the results.

I don't know if there was a later revision CPU board that supported 5.1, or
if only HP-UX 2.1 was officially supported, or what.  The available
information is very thin.

- Josh

Re: Extremely CISC instructions

[Josh Dersch via cctalk]

On Wed, Aug 25, 2021 at 11:19 AM Tony Duell via cctalk <
cctalk@classiccmp.org> wrote:

> On Wed, Aug 25, 2021 at 7:07 PM ben via cctalk 
> wrote:
> >
> > On 2021-08-25 11:08 a.m., Josh Dersch via cctalk wrote:
> >
> > > (The Three Rivers PERQ included a similar "RASTEROP" instruction in its
>
> Well, it might do.There is no requirement for the PERQ machine code
> instruction set to include that, or any other particular instruction.
>

Sure there is -- if it was left out, all of the user code that depended on
it would stop functioning :).  I can remove instructions from the 11/780's
microcode as well, but then it'd cease to be a VAX...

- Josh

Re: Extremely CISC instructions

[Josh Dersch via cctalk]

On Mon, Aug 23, 2021 at 5:38 PM Tom Stepleton via cctalk <
cctalk@classiccmp.org> wrote:

> Hello,
>
> For the sake of illustration to folks who are not necessarily used to
> thinking about what computers do at the machine code level, I'm interested
> in collecting examples of single instructions for any CPU architecture that
> are unusually prolific in one way or another. This request is highly
> underconstrained, so I have to rely on peoples' good taste to determine
> what counts as "interesting" here.
>

I'll submit the Xerox Alto, with its extensions to the base DG Nova
instruction set.  It included "CONVERT", used to render font glyphs to the
screen, and of course the legendary "BITBLT" for transferring bitmaps
across arbitrary bit boundaries.  Both of these were complicated
operationst, and the latter revolutionized computer graphics...

See p. 18 and 22 of http://bitsavers.org/pdf/xerox/alto/AltoHWRef.part1.pdf.


(The Three Rivers PERQ included a similar "RASTEROP" instruction in its
repertoire, which was similar to BITBLT but also allowed for various
logical operations to be applied to the source and destination.)

- Josh

ISO: DEC H317-B (DH11) bulkhead panel

[Josh Dersch via cctalk]

Hi all --

Recently picked up a DH11-AD and now I just need to track down an
appropriate bulkhead panel to go with it.  Originally this would have been
the H317-B, I'm not sure if there were others that are directly compatible,
but if anyone has one lying around drop me a line!

Thanks!
- Josh

Re: Items Wanted

[Josh Dersch via cctalk]

On Tue, Jul 20, 2021 at 4:06 PM Jay Jaeger via cctalk 
wrote:

> On 7/20/2021 6:59 AM, Eric Moore wrote:
> >
> >
> >  >> 11) ESDI disk emulator
> >  >
> >  > I am not aware of any such beasties in the wild.  MFM, yes, but I
> > haven't seen ESDI.   I would love for such a thing to exist,
> > thinking of my Apollo, 3B2 and IBM RT/PC workstations.
> >
> > I’d also love to have one of these, preferably using SD or CF
> > cards.  The Webster WQESD/04 card is a fantastic card, it’s only
> > downfall is that it works with ESDI drives, rather than SCSI, and
> > they’re big and loud. :-)
> >
> > Zane
> >
> >
> > http://www.datexdsm.com/ESDI.php  is
> > what I was thinking of. There are a couple other commercial models out
> > there on offer, no one seems to have one though in the discord or
> > apparently here :)
> >
> > -Eric
> >
> >
>
> I fear these, as well as those shown on one or two other websites, are
> vapor-ware.  The MFM emulators all seem out of stock, the ESDI emulator
> (DWX750) "documentation" is not even a page - just a "blurb".
>
>
I had a similar experience with a set of emulators made by Arraid -- LCM
inquired about one of their SMD emulators (
https://www.arraid.com/data-storage-products/product/aem-1.html) and the
response we got was "we can no longer source the parts to manufacture
these, we have a few remaining in stock that we will sell for $10,000 a
piece."  We did not purchase one.

I suspect that even if you could find someone to sell you one of these
emulators, they would be extremely expensive.  I have never seen one for
sale on the used market.  If you find one, consider yourself lucky.  If
anyone *DOES* have one of these SMD emulators and wants to find a new home
for it, do drop me a line.

- Josh




> JRJ
>

ISO: Docs for Mostek MK8009-CA omnibus memory

[Josh Dersch via cctalk]

Hey all --

Picked up a memory board for my PDP-8/A, it's a Mostek MK8009-CA, currently
outfitted with 32KW of memory but with empty pads for another 32KW.  Not a
ton of documentation on this -- anyone have anything?  At minimum,
configuration information would be nice, I'd also like to know what it
takes to upgrade it to 64KW (apart from 24 more 4116's), so schematics
would be excellent.  I have this weird idea about extending TSS/8 to use
more memory and the advanced features of the KT8-A...

- Josh

Re: Who has a working Terak?

[Josh Dersch via cctalk]

On Sat, Jun 19, 2021 at 5:41 AM John Foust via cctalk 
wrote:

>
> One of the original UCSD Pascal team contacted me, asking if
> any of my Teraks are still working.  Sadly, they don't.
>
> I seem to remember hearing on the list that someone had re-capped and
> re-socketed their Terak, and that it's working.
>

That might have been me.  I have a working Terak and can set it up to
demonstrate stuff, though I may need to find a better camera for capturing
video...

- Josh


>
> He wants to get video of an original, working Terak to demonstrate
> the UCSD Pascal menu system.  He wants to show how the UCSD Pascal
> menu system could've influenced Apple's menus on the Lisa.
>
> Yes, I pointed out that you can run it under emulation.
>
> - John
>
>

Re: PDP-11/05 (was: PDP-11/05 microcode dump?)

[Josh Dersch via cctalk]

On Mon, Jun 14, 2021 at 10:34 PM Tom Uban via cctalk 
wrote:

> On 6/14/21 3:39 PM, Noel Chiappa via cctalk wrote:
> > > From: Tom Uban
> >
> > > it has the early version M7261E Control Logic & Microprogram board
> and
> > > the later version M7260 Data Paths board
> >
> > Ah, I'm glad someone found all that stuff I wrote up there useful. As
> always,
> > I _think_ I got it all transcribed correctly, but do be on the lookout
> for
> > errors!
> I most certainly did - thank you for creating it!
> > > it seems like an older/newer combination, but maybe that was
> common. I
> > > would not have guessed that the four possible combinations would
> all
> > > work together, but maybe they do?
> >
> > I honestly don't know. As far as I can tell, the DEC documentation
> doesn't
> > even _mention_ the two different board generations; perhaps a sign that
> they
> > are functionally interchangeable? (Although even the section on baud
> rate, in
> > both DEC-11-HKDBB-A-D and EK-KD11B-MM-001, 4.11, doesn't even mention the
> > early board. So maybe the manual just ignores the earlier version
> completely?)
> >
> > I don't have an /05 up and running at the moment, or I'd check all 4 and
> see
> > if they all work.
> >
> > > Presently, the machine sometimes runs relatively well and other
> times
> > > it does not.
> >
> > What are the failure symptoms? (It's almost certainly going to take a
> 'scope
> > to fix it; I expect you have one?)
> I have KM11s, a scope, a logic analyzer, a unibone, shiresoft unibus
> analyzer, etc.
> No shortage of gear, just a shortage of time.
> > I'd start by monitoring the CPU clock, and make sure it's running when
> the
> > failure happens. (Note that the front console is handled by the
> microcode, so
> > if the microcode isn't running, the machine will be totally dead.
> > EK-KD11B-MM-001 has a good description of how that works.)
> I think I checked the clock when I started this project a while back, but
> I will
> check it again. Unfortunately, I haven't figured out how to provoke two
> states,
> but it mostly picks the completely dysfunctional state, so I'll look at
> the clock.
> > > my initial messing with KM11 boards, reveals that I can step the
> > > microcode with a KM11 in either the #1 or #2 position, but when two
> > > KM11s are installed at the same time, they do not function properly
> > > together. Is this expected or do I have an issue there too?
> >
> > Not sure. EK-KD11B-MM-001 (available at:
> >
> >   http://www.bitsavers.org/pdf/dec/pdp11/1105/EK-KD11B-MM-001_Jan75.pdf
> >
> > and definitely something you need) says, at pg. 5-6 "KM11 switches have
> the
> > same function in slots KM-1 and KM-2", and on 5-7 "permits the user who
> has
> > only one KM11 to plug into either KM-1 or KM-2".
> >
> > So that _sounds_ like you should be able to plug two in together. The
> first
> > indicates that the switches, the only input to the KD11-B from the KM11,
> are
> > wired in parallel, and the only other thing on the KM11 are the lights,
> > outputs. And why mention "user who has only one KM11", if having two is
> no
> > use because one can't use two at once?
> I've read that doc, but did not come away with the impression that both
> can be used at the same time or not.
>

Just to provide some real-world data, I used a pair of KM11's to debug my
11/05, see the picture here:

http://yahozna.dyndns.org/scratch/1105-debug.jpg

They worked fine.  (These are clones, from Guy Sotomayor's kit.)  I can
verify tonight whether I have the earlier or later rev CPU set, if that
helps.

- Josh

ISO: DW8E parts

[Josh Dersch via cctalk]

Hi all --

I picked up a DW8E backplane from a friendly listmember this week and now I
just need to find parts to populate it (a simple task, right?); I'm hoping
to use it with my negibus PDP-8/I for my ongoing TSS/8 project(*) (in order
to provide numerous serial lines and if I get really ambitious/lucky, an
RK05).

It looks like I need an M7101 and four M7103's.  I intend to build the
cabling myself unless anyone has a set of single-to-Y (BC08D) I/O cabling.
Also on the hunt for a chassis to put these in; this is identical to the
one used for the PDP-8f/m (but sans blinkenlights).

Thanks!
- Josh

(*) RF08 restoration is underway and emulation of multiple RS08s is in
progress...

Re: Writings on AI from 17 years ago....

[Josh Dersch via cctalk]

On Tue, May 25, 2021 at 6:35 AM Tom Hunter via cctalk 
wrote:

> I have learned not to trust any computer museum to properly look after any
> artefacts in the long run. I have seen the following:
>
>- they lose funding and shut down;
>- the building they had for free is sold or demolished and the
>collection no longer has a home;
>- museum management changes and they decide to no longer display certain
>objects;
>- they replace real objects with fancy multimedia presentations;
>- they suck in anything and everything and send unwanted items or
>duplicates to the dumpster rather than trying to find a new home for
> stuff
>they don't want or need;
>
> Don't trust that museums will abide by your wishes when you donate an item.
> They almost never will no matter how secure you think your agreement with
> them is.
>
> I believe that enthusiastic and competent individuals will look after
> valuable items much better than most museums can.
>

Based on the number of items I've rescued from rotting garages, basements,
and warehouses owned (or formerly owned) by enthusiastic and competent
individuals with the best of intentions -- both as part of my former job
and my ongoing hobby over the past 20+ years -- I can say with confidence
that this, uh, may not be strictly true.

Pay your rent.  Keep the roof on your garage in good condition, and keep
the rodents out.  Know when to stop collecting.   *** Make a will, and have
a succession plan that's more than "my significant other will know what to
do" ***

- Josh



>
> Best regards
> Tom Hunter
>
> >
> >
>

Re: PDP-8/I Negative-bus termination

[Josh Dersch via cctalk]

On Wed, May 5, 2021 at 12:27 AM Vincent Slyngstad via cctalk <
cctalk@classiccmp.org> wrote:

> On 5/5/2021 12:03 AM, Josh Dersch via cctalk wrote:
> > Until this point I've never had any peripherals for my negibus systems
> > (apart from teletypes), and it occurs to me that I have no idea if the
> bus
> > needs to be terminated (and if so, with what).  There are 6 slots in the
> > RF08 backplane (D01-D06) for daisy-chaining to the next device, which is
> > where I assume they'd go; the RF08 manual does not make it clear what
> this
> > looks like or if it's actually required, and I've gone through the
> > available PDP-8/I docs and I'm still at a loss.
> >
> > Can anyone with negibus experience point me in the right direction?
>
> I don't have any actual Negibus gear except a TC01 (which I've yet to be
> able to cable to anything), so I'm likely not the best expert.
>
> Regardless, my understanding is that it is terminated in basically the
> same way as the positive bus, which is to say you stick a G717 in the
> BAC connector that has the IOP and TS signals on it (at the far end of
> the bus, of course).
>
> This has the effect of terminating the signals that need to be cleanest
> with 100 ohm resistors to ground.
>
> Not sure where I read that though, so I'm not able to easily double
> check my memory.
>

Thanks!  Looking at the engineering drawings and other docs for the RF08 (
http://bitsavers.org/pdf/dec/pdp8/disc/DEC-08-HIEA-DA_RF08_Jun70.pdf):

Section 2.2.5 of the manual states "Figure 2-5 shows proper cable
connections between the RF08 Disk Control and the central processor and
proper termination techniques at the time of installation."  In figure 2-5
(p. 25) there's the cabling diagram and no explicit termination
instructions called out for slots D01-D06; however, looking closer at the
IOP signals, the lines coming out of the block terminate in a circle, as do
the T1, PCL, and B RUN signals.  Is this circle DEC shorthand for
"terminate this?"

Additionally, on p. 88, there are a series of asterisk-denoted 100 ohm
resistors (connected to the IOP1/2/4 signals) which I assume are meant to
be on the backplane.  On other schematic pages there are other 100 ohm
resistors (with asterisks) for T1, PCL, etc.  These don't appear to be
present on mine; there's a note on p. 88:

"* 100 OHM TERMINATING RESISTORS ARE USED ONLY ON THE PDP-8 NOT ON THE
PDP-8I"

which would likely explain it.  Based on this, I /think/ I'm OK termination
wise with my system. Wonder why there's a difference between the two
systems...

- Josh



> Vince
>

PDP-8/I Negative-bus termination

[Josh Dersch via cctalk]

Hey all --

I cabled up the RF08 to my 8/I this evening and it's showing some very
faint signs of life -- a DIML instruction appears to do the right thing.
That's about it.

Until this point I've never had any peripherals for my negibus systems
(apart from teletypes), and it occurs to me that I have no idea if the bus
needs to be terminated (and if so, with what).  There are 6 slots in the
RF08 backplane (D01-D06) for daisy-chaining to the next device, which is
where I assume they'd go; the RF08 manual does not make it clear what this
looks like or if it's actually required, and I've gone through the
available PDP-8/I docs and I'm still at a loss.

Can anyone with negibus experience point me in the right direction?

Thanks,
Josh

Re: DEC PDP-11/45 backplane +5 ECO

[Josh Dersch via cctalk]

On Sun, Apr 25, 2021 at 11:26 PM Fritz Mueller  wrote:

>
> > On Apr 24, 2021, at 7:02 PM, Josh Dersch  wrote:
> > If you have notes on re-creating the harness, let me know.
>
> Hi Josh,
>
> A few pointers -- I think I left some of these in a comment on one of your
> fb posts, but will repeat here in case others may find it useful:
>
> * The wire list in the commonly available Jun74 11/45 engineering drawing
> set is actually for the power harness, and not for the backplane.  It
> includes wire run lengths in inches, which is quite handy.  I believe it is
> for the newer harness, but there is much overlap.
>
> * The old and new harnesses are also schematically illustrated on four
> pages of the drawing set marked "power systems configuration".  These
> drawings are complete and quite good.
>
> * Drawings for the power distribution board for the older wiring style
> (vertical at the back of the cabinet) are hidden in the Jun74 11/*40*
> engineering drawings (upper right of sheet BA11-F0).
>
> * What I did was use the wire list lengths as a guide, cutting each run to
> length plus a little extra.  I then started with the H742s on the bench, at
> the regulator and power monitor mate-n-loks.  Then put the H742s in the
> rack with the CPU cabinet, and worked my up and over the and then down
> along the along the backplane toward the console, bundling and trimming to
> length as I went.
>
> * A good ratchet lock crimp tool makes a big difference here.  You want
> one with a die that can handle 14 AWG, and on which will crimp both the
> electrical and strain-relief parts of the pins in one go.
>
> * Sticking with the original wire color code also makes it a lot easier
> not to get lost and later to double check and troubleshoot your work.  I
> used MTW ("Machine Tool Wire"), which is available from wirebarn.com at
> 14 and 18 AWG in most of the necessary colors and in 25 and 100 foot
> lengths (I think the 18 AWG purple I had to find separately on eBay, but I
> have lots of leftover of that and will gladly send you some.)
>
> * I skipped wiring for most of the regulators in the bottom H742 (I have
> regulator F there, but none of H, J, K, or L are populated) because I don't
> have any core or fastbus memory in my system.  I figure I can add this
> later if I ever do find myself with either of these.
>
> Good luck!
>

Thanks!  I may get started on that fairly soon, we'll see how ambitious I'm
feeling...

Sorry for the delay, but finally, here's a pile of pictures of the +5V ECO
on the backplane.  Let me know if you need more detail on something:

https://1drv.ms/u/s!Aqb36sqnCIfMpMAqf_6YvmsEEU-T0A?e=Y6WBfV

- Josh


>   --FritzM.
>
>

Re: DEC RF08/RS08 module placement info

[Josh Dersch via cctalk]

On Fri, Apr 30, 2021 at 2:24 PM Mattis Lind  wrote:

> I did another check of the drawings and found a module list.
>
> Initially I was looking for something more graphic then I found this:
>
> https://imgur.com/a/hzmhwQ4
>
> Hope it helps.
>
> /Mattis
>

Thanks so much, both for the pictures of your RF/RS08 and of the
engineering drawings, those will be extremely helpful.  I've never seen
those drawings before, the module list you have is definitely not in the
ones available on Bitsavers.

- Josh

Re: DEC RF08/RS08 module placement info

[Josh Dersch via cctalk]

On Sun, Apr 25, 2021 at 1:55 PM Mattis Lind  wrote:

>
>
> Den sön 25 apr. 2021 kl 22:43 skrev Josh Dersch via cctalk <
> cctalk@classiccmp.org>:
>
>> Hi all --
>>
>> In addition to the 11/45 project I'm also working on restoring an
>> RF08/RS08
>> fixed head disk/controller (in the vain hopes of one day running TSS/8 on
>> my PDP-8/I).  I have the power supply repaired and running and I'm getting
>> ready to power the logic up (the disc itself will be a project all its
>> own,
>> once it arrives).
>>
>> I'd like to double-check that all the flip chips are in their right
>> places;
>> I have no cause to think they've been shuffled around but I want to be
>> sure.  The engineering docs have detailed schematics but no placement
>> chart
>> for the modules themselves.  Given enough time with the schematics I could
>> derive this chart but I'm saving that as a last resort.  So, two
>> possibilities here:
>>
>> 1) Does anyone know of a document I've overlooked that includes module
>> placement?
>> 2) Can someone with an RF08 and/or RS08 take a few detailed pictures of
>> the
>> logic (from the handle side, of course) so I can compare?  (Note: the
>> available RF08/RS08 pictures on the 'net are of the unit currently in my
>> possession, so are not useful in this regard!)
>>
>>
> I have a RF08 / RS08 combo. It was connected to a PDP-8/L, but the cabinet
> with the DW08 was missing.
> I can take a bunch of pictures next weekend.
>
> I have a vague idea that I have a bunch of docs with the unit. Double
> ledger size or around A2. I will have a look.
>

Thanks!  That will be very helpful!


> Would be very interesting to read your story when repairing it!
>

I'm going to try to write about it, we'll see how good I am about keeping
up.  Still slowly writing things up about the 11/70 from earlier this year
and I'm behind on just about everything.  I imagine getting an actual
physical disk working is going to be an unlikely prospect, my plan is to
develop some hardware to emulate one or more RS08 drives, eventually.  But
I want to try the real thing first :).

- Josh



>
> /Mattis
>
>
>
>> Thanks!
>> - Josh
>>
>

Re: DEC RF08/RS08 module placement info

[Josh Dersch via cctalk]

On Sun, Apr 25, 2021 at 1:56 PM Vincent Slyngstad via cctalk <
cctalk@classiccmp.org> wrote:

> On 4/25/2021 1:42 PM, Josh Dersch via cctalk wrote:
> > 2) Can someone with an RF08 and/or RS08 take a few detailed pictures of
> the
> > logic (from the handle side, of course) so I can compare?  (Note: the
> > available RF08/RS08 pictures on the 'net are of the unit currently in my
> > possession, so are not useful in this regard!)
>
> This one might be useful for comparison:
> https://www.computercollection.net/index.php/disk-drives/
> https://www.computercollection.net/wp-content/uploads/2019/06/IMG_2241.jpg
> It's a little out of focus toward the bottom.
>
> https://www.computercollection.net/wp-content/uploads/2019/06/IMG_2243.jpg
> Only one side of the drive electronics appears to be visible.
>

Yeah -- this is a picture of the exact unit currently in my possession.  So
it matches 100% but tells me nothing useful ;).

- Josh


>
> Vince
>

DEC RF08/RS08 module placement info

[Josh Dersch via cctalk]

Hi all --

In addition to the 11/45 project I'm also working on restoring an RF08/RS08
fixed head disk/controller (in the vain hopes of one day running TSS/8 on
my PDP-8/I).  I have the power supply repaired and running and I'm getting
ready to power the logic up (the disc itself will be a project all its own,
once it arrives).

I'd like to double-check that all the flip chips are in their right places;
I have no cause to think they've been shuffled around but I want to be
sure.  The engineering docs have detailed schematics but no placement chart
for the modules themselves.  Given enough time with the schematics I could
derive this chart but I'm saving that as a last resort.  So, two
possibilities here:

1) Does anyone know of a document I've overlooked that includes module
placement?
2) Can someone with an RF08 and/or RS08 take a few detailed pictures of the
logic (from the handle side, of course) so I can compare?  (Note: the
available RF08/RS08 pictures on the 'net are of the unit currently in my
possession, so are not useful in this regard!)

Thanks!
- Josh

Re: DEC H742a Power Supplies, for Parts (Seattle)

[Josh Dersch via cctalk]

On Sat, Apr 24, 2021 at 12:37 PM Ethan Dicks  wrote:

> On Sat, Apr 24, 2021 at 2:51 PM Josh Dersch via cctalk
>  wrote:
> > Fans are dead (either melted away entirely or rusted
> > out).
>
> Are any of those melty fans Boxers?  I'm still looking for a circlip
> to put a Boxer back together for an Omnibus box (for those that
> haven't heard the story, I was cleaning and lubing a fan and the clip
> leaped to freedom, never to be found).
>

Thanks for reminding me, I'll take a look.  There look to be three Boxers
in the upper supply (which didn't melt but are very rusty).  If they match
what you need, I'll see if I can liberate some circlips from them.

I'll also pull off the mounting bracket for the front panel for you.  I
think it may be the only salvageable part from it (unless anyone needs an
aluminum light mask from an 11/45 front panel).

- Josh


> I sent a picture before of the fan type and of the circlip.  I can
> resend if needed.   I don't need the entire fan, just that one tiny
> metal part.
>
> -ethan
>

Re: DEC PDP-11/45 backplane +5 ECO

[Josh Dersch via cctalk]

On Sat, Apr 24, 2021 at 1:36 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

> Hi Josh,
>
> Among the pictures linked from your message about the H742a parts, there
> is one picture of you backplane.   I have been looking for some time for
> information about the following 11/45 ECO:
>
> > KB11-1 CODE: D May-72 [ECO]
> >
> > Problem: Etch carrying +5V current from Mate-n-Lock pins to backpanel
> pins is not heavy enough to carry required current. Correction: Run 24AWG
> wire in parallel with etch on panels which already have Mat-n-Lock assembly
> installed. Increase thickness of conductor with solder bead if Mate-n-Lock
> assembly not installed. PDP-11/45 system serial number 101 and later.
>
> The wiring arrangements at the top of your backplane look to be a bit
> different from mine, and I believe you may have this ECO implemented.
> While you have your backplane out, could I ask that you take some closeups
> around the Mate-n-Locks along the top?  I'd be very interested to see the
> board traces and the details of the red bus wiring there.
>

For sure.  I have it on a shelf in the garage to keep it relatively safe
while it's out of the chassis, next time I'm out there I'll take some
pictures.


>
> Pictures of the toasted 11/45 suggest that the original machine had the
> older power wiring scheme (distribution panel mounted vertically on back of
> cabinet instead of horizontally at top of cabinet, etc.) although your
> KB11A serial number badge is >2000, which is curious...


Yes, I was looking at the service docs and it does seem to match the
earlier wiring scheme.  If you have notes on re-creating the harness, let
me know.  The molex shells actually survived the heat (with a couple of
exceptions) so I should be able to reuse them. Looks like I'll just need to
order up a ton of wire and pins (and a crimper, probably).

I'll get the 15V boards out of the H742's this week.

- Josh

DEC H742a Power Supplies, for Parts (Seattle)

[Josh Dersch via cctalk]

Hey all --

I've started stripping down the "fire-sale" PDP-11/45 I picked up in
November, in preparation for sanding and repainting the rack and processor
chassis.  There were two H742a supplies in the rack that I believe are too
far gone to be reasonably restored (in particular the heat definitely did a
number on at least one of the transformers) and I have a pair of H7420a's
ready to take their place.  I hate to see things go to waste, though, and
even though it's probably pointless -- before I send these off to the
scrapyard, I wanted to check to see if anyone here needed any parts.
Shipping the whole unit(s) would be pretty expensive, local pickup is an
option if you want the whole thing(s).  The transformers are a bit toasty
but the power supply boards look like they might be usable after a good
cleaning and testing.  Fans are dead (either melted away entirely or rusted
out).  I suppose there's not really much else that'd be useful to anyone
but I have a compulsion to make sure...

Here's a couple of pictures:
https://1drv.ms/u/s!Aqb36sqnCIfMpL89R2GtJFrrRqZ1vQ?e=Re3KZr

And for fun, here's a bunch of pictures of the unit just prior to the
teardown:  https://1drv.ms/u/s!Aqb36sqnCIfMpL8-mTCp-NndzDTpbw?e=8aWCl4

(I do think there's a good chance this will run again, the major casualties
were the front panel, power supplies, and wiring harness.  I have
replacements for the first two, and the third is just a matter of taking
the time to build a new one.  The boards cleaned up nicely and there's no
real damage to the processor backplane, amazingly.)

- Josh

Re: Is this a new record?

[Josh Dersch via cctalk]

On Thu, Apr 22, 2021 at 7:33 PM Chris Zach via cctalk 
wrote:

> Not anymore. I still need to figure out if/how to get the big monitor
> out, but the little one is safe, as are two digitizers (one complete), a
> mouse thing, and a keyboard.
>

I am still on the hunt for a PERQ keyboard and display for a unit I
recently acquired, though it's far from urgent.


>
> And so many floppies. Oi.
>

If you need help imaging them, I'm happy to share the load.

- Josh



>
> C
>
>
> On 4/22/2021 10:30 PM, Al Kossow via cctalk wrote:
> > On 4/22/21 5:08 PM, Chris Zach via cctalk wrote:
> >> Jesus, I just traded a Perq1 keyboard to a guy for a $100 donation to
> >> a food bank of his choice.
> >
> > josh dersch is looking for a keyboard and a monitor
>

Is this a new record?

[Josh Dersch via cctalk]

https://www.ebay.com/itm/164815576309

$9570 for a keyboard.

As much as I'd like to find a keyboard for my Lambda's second head, I
somehow doubt that's going to happen.  And now I think I need to go find a
really, really (really) safe place to keep the keyboard I *do* have...

- Josh

Re: RSX11D disks on EBAY- anyone interested?

[Josh Dersch via cctalk]

On Tue, Apr 6, 2021 at 10:59 PM Ethan Dicks via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, Apr 6, 2021 at 11:48 PM Al Kossow via cctalk
>  wrote:
> > On 4/6/21 8:31 PM, Noel Chiappa via cctalk wrote:
> > >  > From: Al Kossow
> > >
> > >  > I have to find my qbus rk11 card.
> > >
> > > The RKV11-D is a set of 4 quad cards
> >
> > It isn't that, it's a single-card controller made
> > by Xylogics. Thanks for playing.
>
> One of these?
>
> http://www.bitsavers.org/pdf/dilog/brochures/DQ100_Brochure_Aug1980.pdf
>
> Looks neat.  I could have used one of those 25-30 years ago.
>

The Dilog is a different board.  Incidentally I have one of these, but I
haven't found any documentation for it.  Would love to know the header
pinout so I can build a cable...

- Josh



>
> -ethan
>

Re: Help with PCB ID

[Josh Dersch via cctalk]

On Sat, Mar 13, 2021 at 11:43 AM Cory Heisterkamp via cctalk <
cctalk@classiccmp.org> wrote:

> I’m wondering if anyone recognizes this PCB.  Double-sided, 74xx vintage,
> measuring 14”x15”. There’s a “B.I.” logo in one corner, but no google
> match. IC date codes are ’77/’78 vintage.
>
> There’s a pair of DB-25’s, a BCD encoder, and for some reason, two pots.
> DC rectification appears to take place onboard. I thought perhaps the
> 112-7753 marking might be a part or catalog number, however the flip side
> is marked 112-1754, so perhaps not.
>
> Anyone recognize it?  -Cory
>
> https://photos.app.goo.gl/dogAPxn7vLV87YRw9
>
>
My guess is it's a logic board from a Beehive International terminal.  No
idea what model though.

- Josh

Re: DF32?

[Josh Dersch via cctalk]

On Tue, Mar 9, 2021 at 3:39 PM Ethan Dicks  wrote:

> On Tue, Mar 9, 2021 at 6:10 PM Josh Dersch via cctalk
>  wrote:
> > I have a bid on it right now, I was hoping to use it with my straight-8,
> > should I be so lucky to win it.  Don't want to collide with you,
> however...
> >
> > - Josh
> >
> > On Tue, Mar 9, 2021 at 3:04 PM Chris Zach via cctalk <
> cctalk@classiccmp.org>
> > wrote:
> > > There's a DF32 on Ebay. I've got a bid in on it, will see what happens.
>
> So did one you bid over $1500?
>

Not I.  I wonder what the high bidder's max was...

I feel kinda stupid, given that the thing's original BIN was $1500; I
wasn't going to go that high on it but a friend of mine offered to chip in
at the last minute so I got outbid by $25 over the original BIN price.

It's OK, I have enough projects as it is and I definitely didn't need to
spend more money.

- Josh


>
> -ethan
>

Re: DF32?

[Josh Dersch via cctalk]

I have a bid on it right now, I was hoping to use it with my straight-8,
should I be so lucky to win it.  Don't want to collide with you, however...

- Josh

On Tue, Mar 9, 2021 at 3:04 PM Chris Zach via cctalk 
wrote:

> There's a DF32 on Ebay. I've got a bid in on it, will see what happens.
>
> In the unlikely event I win I'll have to build a system to adapt the
> Negibus to the pdp8/L. However did the pdp8/L have 3 cycle data break?
>
> C
>

Re: TSS/8 & dectape

[Josh Dersch via cctalk]

On Sat, Mar 6, 2021 at 3:27 PM David Gesswein via cctech <
cct...@classiccmp.org> wrote:

> I'm having trouble using DECtapes with TSS/8 under SIMH. I tried with both
> the
> RF image and LCM RK05 image and no mater what I do it hangs if I try to
> access a DECtape.
>
> I am trying to use COPY command from account 2.
>
> I attach a dectape in simh then assign it in TSS and then try to get a
> directory or zero the tape with copy. Both hang. Anybody with more TSS
> knowledge know how to get this to work.
>


I've never tried using a dectape as an assignable device in TSS/8; have you
tried using PUTR?  I used that a number of times on the TC08 setup at LCM
to transfer files and it seemed to work (once I fixed the bug I introduced
into the LCM TSS/8 code inadvertently -- the latest stuff on github should
be correct.)

>
> Images from bitsavers
> http://www.pdp8online.com/ftp/images/bitsavers/unknown/
> 7196, 7211, 7242, and 7280 have text where TSS/8 was mentioned. These are
> the
> ones I wanted to use TSS to see if I can get a directory.
>
> 7241, 7253, 7264, 7265, 7275, 7278, 7291, 7292 have contents but nothing I
> can identify.
>

Ooh, let me know if you find anything.

- Josh


>
> There are also some LINCtapes that had read issues so unable to determine
> what the are.
>
>
> What I have decoded
> http://www.pdp8online.com/images/index.shtml
>
> See last 3.
>
>

Any interest in a Floating Point Systems AP-120 array processor?

[Josh Dersch via cctalk]

I picked this up a number of years ago for reasons that entirely escape
me.  It's certainly neat, but I don't see myself ever actually using it and
it's large and heavy.

Documented here:
http://bitsavers.trailing-edge.com/pdf/fps/7259-02_AP-120B_procHbk.pdf

Mine appears to have a DEC-style interface but I'm unsure what it talks to
on the DEC side of things.

I can take pictures if there's interest, but it's fairly nondescript, just
a large white box with rack-mount ears and a small panel with some switches
on it.

It's in the Seattle area if anyone wants it, and it's free!  Shipping is...
not something I really want to think about right now.

- Josh

ISO: Stabilization feet for DEC H960 rack

[Josh Dersch via cctalk]

I realize these are uncommon; curious if anyone has a spare pair somewhere
(hey, that rhymes.)  I'd like to be able to pull out the CPU on my 11/70
without worrying about the whole thing tipping over and crushing people I
care about.  It's the little things, really...

Thanks!
- Josh

Re: Massbus - was: Re: VAX 11/750

[Josh Dersch via cctalk]

On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk 
wrote:

> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
> > Oh this is fun stuff. Is there a specification write-up anywhere on the
> MASSBUS overall?
>
> there is some documentation on bitsavers
>
> the register descriptions were intentionally obfuscated to prevent cloning
> that was figured out to make SIMH work
>

Interesting... Is this obfuscation documented anywhere (beyond looking at
SIMH code?)  I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)

- Josh



>
> the CDC drive interface was also slightly modified for the same purpose
>

Re: PDP-11/70 progress (and a cry for help)

[Josh Dersch via cctalk]

On Wed, Feb 17, 2021 at 12:45 AM Josh Dersch  wrote:

>
>
> I hooked the LA up to the two PROM bits that select the AMX input (RACC
> UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board.  These
> come from the PROM at U101 and go through a 74S174 at E97 before heading
> over to the DAP board.  And during FET.00 we have:
>
> Addr PCB PCA AMX
> 260  44  44  0
>
> "0" here selects DR (Destination Register) input to the mux and is
> incorrect; it should be 1 (PCB).  During a single-instruction-step run,
> this value reads out OK on the analyzer.  I noted a few other discrepancies
> in the capture (all of which match the ucode listing during a
> single-instruction step) which makes me think that the high outputs of the
> PROM are right on the bleeding-edge of acceptable TTL.  I checked out the
> signal on the scope while running a BR .-1 instruction (which also doesn't
> execute correctly but at least doesn't halt... I don't have a storage scope
> to capture this during a single instruction execution) and it looks like
> the voltage swing is from about 0.15V to 1.7V or so.
>
> On the off chance it was the 74S174 at E97 pulling the signals down, I
> socketed it and substituted a spare '174 in; no change.  I also noted that
> the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it
> made a difference (it did not.)
>
> So it seems likely it's the PROM.  Looks like I may have some typing to
> do, though given that the ROM works well enough at slow speeds I might be
> able to dump it with my Data I/O Model 29 and compare it against the
> listings in the engineering drawings, to save some time...
>
> I'll try to dump the PROM tomorrow and see what I get.
>
> - Josh
>


A status update here:

I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29,
comparing it with the listing in the engineering drawings).  A local friend
had a spare 11/70 boardset, so while I wait for some (hopefully) NOS
bipolar PROMs to arrive, I've installed a spare RAC board.  With this
installed, instructions execute much better, and after tracing down a
faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301!

I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the
past week I've been running diagnostics and debugging the hardware.  Thus
far:

- Unibus Map registers non-functional:  addresses decode but writes have no
effect and all reads come back as "0". Replaced bad 8640 bus receiver on
the Unibus Map board.
- EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00),
in PAUSE.  Traced it down to the HC42 (replaces the original Cache Control
Board) board of the Hypercache boardset, lacking any engineering info I
swapped this for a spare that I'm fortunate enough to have.

The system is now passing all but two diagnostics:
- EMKA reports strange errors in banks 50-57 of memory and only with
pattern 17; all other banks test fine:
MEMORY DATA ERROR
  PCBANK  VADD PADD GOOD BAD XOR  MAR BOX MTYPE INT PAT
ARRAY
032334   50  157564  05077564  000377  000377  00  0   ?   MJ11  ?   17
 ??
032334   50  156450  05076450  000377  000377  00  0   ?   MJ11  ?   17
 ??
032334   50  155330  05075330  000377  000377  00  0   ?   MJ11  ?   17
 ??
032334   50  154210  05074210  000377  000377  00  0   ?   MJ11  ?   17
 ??
032342   50  154020  05074020  000377  17  177400  0   ?   MJ11  ?   17
 ??
032342   50  153740  05073740  000377  17  177400  0   ?   MJ11  ?   17
 ??
032342   50  153734  05073734  000377  17  177400  0   ?   MJ11  ?   17
 ??
032342   50  153732  05073732  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153730  05073730  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153726  05073726  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153724  05073724  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153722  05073722  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153720  05073720  000377  177400  17  0   ?   MJ11  ?   17
 ??
032342   50  153716  05073716  000377  177400  17  0   ?   MJ11  ?   17
 ??

Occasionally testing banks 50-57 will die with a trap to 4 instead.
Pattern 17 tests using alternating patterns of "0" and "1" bytes, using
byte accesses to memory, I'm curious why only this pattern would fail.
Accesses to this area of memory from the console work fine

- EKBD fails with:

ADDRESS MULTIPLEXER, AMX, CPU INPUTS TEST FAILED.
ERROR ADDRESS REGISTER NOT SET CORRECTLY.
  TEST. CALL AT PC. EXPECTED ADRS.  GOT ADRS.   ERROR REG.
 5  752406000576144406

(Note the similar address range to the EMKA failures).  I've verified that
AMX, etc. are not to blame here.  I suspect this issue is related to the
memory issue above.

I've looked at the MMU hardware to see if address generation is breaking
for some reason at these addresses and it seems to be OK.  I'm going to
keep 

Re: PDP-11/70 progress (and a cry for help)

[Josh Dersch via cctalk]

On Tue, Feb 16, 2021 at 5:08 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

> > On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk <
> cctalk@classiccmp.org> wrote:
> > So you could set up on t4 or t5 of that microinstruction with the KM11...
>
> > On Feb 16, 2021, at 11:08 AM, Josh Dersch  wrote:
> > I can't, though -- all of this stuff works fine when running slowly :)
>
> Oh right -- I keep forgetting that part!  So that really does leave you
> with just the LA to catch things in the act I guess.
>
> > Right now I'm thinking it is most likely the AMX selecting the wrong
> input (I'm guessing that BMX is correctly selecting KOMX, to get the
> constant "2" for the add operation).
>
> I agree; seems a good place to look next.
>

I hooked the LA up to the two PROM bits that select the AMX input (RACC
UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board.  These
come from the PROM at U101 and go through a 74S174 at E97 before heading
over to the DAP board.  And during FET.00 we have:

Addr PCB PCA AMX
260  44  44  0

"0" here selects DR (Destination Register) input to the mux and is
incorrect; it should be 1 (PCB).  During a single-instruction-step run,
this value reads out OK on the analyzer.  I noted a few other discrepancies
in the capture (all of which match the ucode listing during a
single-instruction step) which makes me think that the high outputs of the
PROM are right on the bleeding-edge of acceptable TTL.  I checked out the
signal on the scope while running a BR .-1 instruction (which also doesn't
execute correctly but at least doesn't halt... I don't have a storage scope
to capture this during a single instruction execution) and it looks like
the voltage swing is from about 0.15V to 1.7V or so.

On the off chance it was the 74S174 at E97 pulling the signals down, I
socketed it and substituted a spare '174 in; no change.  I also noted that
the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it
made a difference (it did not.)

So it seems likely it's the PROM.  Looks like I may have some typing to do,
though given that the ROM works well enough at slow speeds I might be able
to dump it with my Data I/O Model 29 and compare it against the listings in
the engineering drawings, to save some time...

I'll try to dump the PROM tomorrow and see what I get.

- Josh

Re: PDP-11/70 progress (and a cry for help)

[Josh Dersch via cctalk]

On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Feb 16, 2021, at 1:13 AM, Josh Dersch  wrote:
> > My money's on t5 going wrong -- an ALU input mux or operation being
> selected incorrectly, possibly.  This also somewhat explains why execution
> doesn't trap due to executing a HALT from an odd address -- it isn't
> actually executing from the wrong address, because the bus address is
> loaded from a still-good PCB in t1.
>
> Yes -- that seems to match the observations.  So you could set up on t4 or
> t5 of that microinstruction with the KM11 in single-clock-phase mode, and
> then have at the ALU with a logic probe to check...
>

I can't, though -- all of this stuff works fine when running slowly :).
It's possible that while running in single-clock mode I might be able to
see a waveform that's slightly off on the 'scope, if I can pinpoint the
failure.

Right now I'm thinking it is most likely the AMX selecting the wrong input
(I'm guessing that BMX is correctly selecting KOMX, to get the constant "2"
for the add operation).


>
> There is a small ALU control ROM on the GRA (E74 in the upper left of
> sheet GRAA), which selects the ALU mode and operation based on lines coming
> over from the IRC.  I had a failure of this part on my 11/45, and ended up
> with incorrect ALU setup in some circumstances.  That part is a 256-bit
> DM8598 tri-state bipolar mask ROM, and the truth table is on sheet GRAK.
>
> Looking back at my notes, I think it was Glen who informed me (on this
> list, in 2016!) that the Signetics 82S123 PROM could be substituted here.
> Programmed one up, and it worked, in case you run into the same thing and
> it is useful info.
>

I think I may have ended up doing a similar substitution with a microcode
ROM on my 11/05.  Have the 11/70 microcode PROMs been dumped?  I had to
recreate the 11/05 PROM from the listings in the engineering drawings...

- Josh



>
> cheers,
>   --FritzM.
>
>

Re: PDP-11/70 progress (and a cry for help)

[Josh Dersch via cctalk]

On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

> Hi Josh,
>
> In the situation you describe, I guess I would first chip clip '174s for a
> slice of both PCA and PBC on the LA, run the troublesome instruction
> sequence, and look at the trace.  Check that CLKPCA H and CLKPCB H are
> happening when and only when expected, and that all the timing there looks
> okay.
>
> You would also be able to see good-data-clocked-in-but-bad-data-presented
> on that trace, indicating more failed '174, or see any bad data arriving
> from the ALU upstream.
>
> I'll take a look through the flows after dinner.  The "0002" might be one
> operand used to increment the PC, but the other operand shows up as all
> zeros because of a bad ALU setup?  I guess I'd trace to definitively rule
> out PCA and PCB first, and then move backward around the chain from there
> verifying the ALU, ALU muxs, mux sources, etc.?
>
> --FritzM.
>

Thanks, Fritz, that's a good idea.  I'm a bit short on dip clips at the
moment so I had to read PCA and PCB on separate passes (and just the low 6
bits); and right now the clock's still hooked up to RACA CLKA RAR H (which
clocks when the ucode ROM address changes) so it's not quite as fine
grained as I'd like (I have to move everything around to get the logic
analyzer's clock signal hooked up to the main clock and it's just too late
tonight...).  But still, this is fairly revealing.  This is an execution of
a MOV #1, R0 instruction poked in at address 40:

Addr PCB PCA
334  40  40
260  40  40
343  42  42
022  42  44
027  44  44
205  44  44
260  44  44
343  03  03
010  03  05
316  03  05
164  03  05
240  03  05
352  03  05
170  03  05

(Note that the sample is taken at the beginning of the microinstruction).

Based on this, it's clear that things get messed up during 260 (FET.10).
The operations performed during this instruction are:

t1: BA <- PCB; BC <- DATI
t2: 
t3: BRQ STROBE
t4: BUS PAUSE
t5: PCA <- PCB + 2
t6 IR <- BUS; BR <- BUS
PCB <- PCA
t3 FPA <- BA

My money's on t5 going wrong -- an ALU input mux or operation being
selected incorrectly, possibly.  This also somewhat explains why execution
doesn't trap due to executing a HALT from an odd address -- it isn't
actually executing from the wrong address, because the bus address is
loaded from a still-good PCB in t1.

More investigation later this week...

- Josh

PDP-11/70 progress (and a cry for help)

[Josh Dersch via cctalk]

Hi all --

Thought you all might be interested in an update, and I'm also looking for
advice in debugging the current issue I'm hitting.

After replacing the clock crystal on the TIG, the system started showing
signs of life, but the Load Address switch would stop working after being
powered on for 10-30 seconds, but would work fine single-stepping via the
KM11.  Brought the DAP board out onto the extender for debugging and the
problem went away.  Reinstalled the board after cleaning the slot (again)
and the problem hasn't recurred since.  First bad backplane connection, I'm
sure it won't be the last.

After this, addresses could be loaded, data could be toggled into memory.
But instructions wouldn't execute; Tracing through the microcode with the
KM11 indicated that the microcode flow was aborting early and returning to
the main console loop (via BRK.90) before the instruction fetch at FET.00;
this was due to the TMCB BRQ TRUE H signal being stuck high.  Probing of
the TMC board revealed a bad 74H30 at E70, which had its output stuck at
1.65V or so, just high enough to confuse things.

Now instructions would execute but the PC would contain garbage after
execution of an instruction, after tracing the microcode and staring at the
flow diagrams all signs pointed to the PCB register (twin to the PCA
register that is used for storing PC data) having trouble.  Garbage in the
PC after execution was always in bits 6-11, everything else was fine, which
pointed to a 74S174 at H47 on the DAP board.  Replaced and now instructions
execute!

Mostly.  They seem to execute properly when single-stepping instructions,
or running off the RC clock at a clock rate of about 16-20Mhz, any faster
than that and things stop working correctly.  This is what I'm currently
banging my head against -- if anyone has any experience with the 11/70 or
wants to stare at the manuals for a bit (and who doesn't?), I'd appreciate
any extra input.

There are a number of different issues, I'm currently focusing on
two-operand instructions that take an immediate argument (MOV #10, R0, or
ADD #42, R5) for example.  The behavior here is a bit befuddling and I
can't quite figure out how it ends up happening, given the microcode.

I'll use ADD as a representative example.

An ADD #10, R0 instruction (followed by HALT) poked in at address 1000
executes properly -- R0 gets 10 -- but afterwards the PC is corrupted: it
contains 2, rather than 1004.  In the general case, "ADD #X, R0" ends with
PC containing 2 + .  (MOV shows the exact same
behavior, except that there's no addition, obviously.)

This value of PC is shown in the Address lights, as well as when examining
the register from the front panel (at 1707).

When single-instruction-stepping the processor this instruction executes
perfectly: R0 gets R0+10, PC is 1004 afterwards (both in the Address lights
and when examining from the front panel).  I have verified with my logic
analyzer that when running normally (i.e. not single-stepping) the
microcode executes the proper sequence of instructions -- which is the same
as executed when single-stepping except at the very end:  In FLOWS 4, after
the D00.90 instruction executes, a branch is taken to BRK.90, which exits
back to the console loop.

I don't believe there should be any other differences in execution between
the two paths -- other than the branch at the end there are no conditional
branches or conditional operations based on whether the CPU is
single-stepping or not.  There's a signal somewhere in there that has just
gone a little bit slow... the trick is finding it.

For reference, the microcode sequence (starting at FET.03, see pg. 5 of
http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) is:

334 (FET.03)
260 (FET.10)
343 (IRD.00)
022 (S13.01)
027 (S13.10)
205 (D00.90)
260 (FET.10)
343 (IRD.00)
010 (HLT.00)
316 (HLT.10)
164 (FET.04)
240 (BRK.90)
352 (BRK.00)
170 (CON.00)

You can see it fetching and executing the ADD instruction, then returning
back to FET.10 and executing the next instruction, which is a HALT
instruction (because all other memory contains 0 at this point).  I believe
this is what causes the "+2" portion of the final (incorrect) PC value.
(What's extra odd -- literally -- here is that if you start with a "1" in
R0, the final PC is 3... seemingly indicating a fetch/execution of an
instruction at an odd address, which you'd think would cause a trap
instead...)

I've been staring at this awhile and I'm puzzled; everything seems to
execute properly, the instruction is fetched and decoded, and the immediate
value is fetched, the ALU does the right thing and the result is properly
stored in R0.  And then the PC gets screwed up, and I'm not quite sure how
that's possible from looking at the microcode, so I'm not quite sure where
to start looking.

I sort of suspect the PCB register again, as this is related to the
difference in behavior between single-stepping and normal execution:  the
branch back to the 

Re: Reading ESDI disks

[Josh Dersch via cctalk]

On Thu, Feb 11, 2021 at 9:45 AM Nigel Johnson via cctalk <
cctalk@classiccmp.org> wrote:

>
> On 2021-02-11 12:41 p.m., Al Kossow via cctalk wrote:
> > On 2/11/21 9:33 AM, Nigel Johnson via cctalk wrote:
> >> I'm about to try the very same thing.
> >>
> >> I have a MicroVAX II with a sigma MSCP ESDI controller.  It can be set
> >> for soft-secoring or various numbers of hard sectors.  That is what I
> >> see is the big issue with these drives.
> >>
> >> A friend gave me two drives that had been written on a PC under *nix.
> >
> > There is little chance this will work for the same reason you can't use
> > an arbitrary disk/controller combination for PC recovery.
> >
> >
> Doesn't stop me trying, Al. Lots of things were achieved by people who
> didn't know they couldn't do it!
>
> My controller has settings for different sector sizes.  I owe it to my
> friend to try!
>

Al's right in this case.  In addition to the controller almost certainly
using a different low-level format than whatever your friend's disk was
written with, you're doubly screwed because you're using an MSCP controller
-- the Sigma's going to expect RCT and FCT blocks somewhere on the unit for
block remapping and since they're not there (and are in fact likely
unreadable due to the difference in low-level format) it will fail.

- Josh



>
>
> Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
> Amateur Radio, the origin of the open-source concept!
> Skype:  TILBURY2591 nw.john...@ieee.org
>
>
>
>
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Fri, Feb 5, 2021 at 12:29 AM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Feb 4, 2021, at 9:45 PM, Josh Dersch  wrote:
> > The 11/70 is now somewhat operable.  I can examine and deposit memory,
> at least for a short while -- after the system warms up for 30 seconds or
> so the Load Address switch stops functioning.
>
> Nice!!
>
> One handy test on '45 is to put the data display knob to bus address; if
> the microcode is still running in the control panel idle loop (halt switch
> down or fault) the data lights will follow along with the toggles.  This is
> a super quick way to tell if the microcode is still running or if it is
> wedged.
>
> (The '45 and '70 microcode seem quite similar, so your '70 might have the
> same feature?  I haven't looked at the flow diagrams yet to know for sure.)
>

Thanks for the tip, I'll check that out.  Before I went to bed I did a bit
more poking.  Upon closer examination, the Load Address switch is still
being recognized:  the Data lights get reset to 0 after it's toggled.  So
the microcode is taking a jump to ADR.00 when the switch is toggled.  It
looks like what isn't happening is the PCA <- BR in T5.  So I have a couple
of places to look -- it's possible that the T5 clock signal is going wrong
after warming up (note that ADR.00 is the only step in the console flow
that does anything in T5, except maybe RDP.00 -- I'm not sure if that's a
"5" or a 3").  (See flow 14, p. 18 of
http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) Or
something's going wrong with the PCA <- BR operation.

I put the KM11 back in, and while single-stepping or running under the RC
clock (which is currently set to a really low clock rate, like 7Mhz, for
some reason) Load Address works fine.  Seems like some component has slowed
down a bit and stops operating correctly at full speed.

Something to poke at this weekend...

- Josh




>--FritzM.
>
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Thu, Feb 4, 2021 at 2:42 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Feb 4, 2021, at 1:51 PM, Josh Dersch  wrote:
> > [RC maintenance clock] Yeah, you'd think... but it doesn't work :).  I
> mentioned earlier in this thread that it's stuck in single-step mode.  From
> the schematics it looks like the crystal clock needs to be running to clock
> some of the flip flops used in the "Source Synchronizer" to select the
> proper clock source.  My guess is that since the clock isn't running, the
> flip flops are left in a weird state.
>
> Oh, interesting!  Noted for future reference.  The TIG is not exactly
> straightforward...


So I realized today that, hey, I have a burned-out 11/45 in the garage, and
it has a TIG (albeit an M8109), and it also has a 33.33Mhz crystal on it.
And because I'm impatient and can't wait for my Digi-Key order to come in,
I went out and borrowed the crystal from the 11/45's TIG and installed it
in the 11/70's.  The 11/70 is now somewhat operable.  I can examine and
deposit memory, at least for a short while -- after the system warms up for
30 seconds or so the Load Address switch stops functioning.  (Happens
gradually, too... for 10 seconds or so it works every other time you toggle
it, then it stops entirely.)  Everything else seems to work properly after
this happens, so I'm kind of curious if there's an IC on the front panel
that's gone bad, though I suppose it's still completely possible it's
something on the CPU end.  I'll have to do some debugging, but it'll have
to wait until this weekend.

As an aside... The M8109 is very similar looking to the M8139... any ideas
what the functional differences are?  There seems to be an extra IC and
some ECO wiring on the M8139.  I'll have to take a closer look someday.

- Josh

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Thu, Feb 4, 2021 at 10:19 AM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Feb 3, 2021, at 8:07 PM, Josh Dersch  wrote:
> > Sure enough, TIGB XTAL H was a flat line.  Nothing happening at the
> crystal itself either.  The crystal's casing was fairly corroded (which is
> interesting, since nothing else on the board is) and after a tiny bit of
> prodding one of the legs fell off, so I'm hoping that's the culprit.
>
> Ah.  One of the switches on the KM11 should enable the machine to run off
> the separate RC maintenance clock on the TIG, if you want to keep going
> before your new crystal shows up.


Yeah, you'd think... but it doesn't work :).  I mentioned earlier in this
thread that it's stuck in single-step mode.  From the schematics it looks
like the crystal clock needs to be running to clock some of the flip flops
used in the "Source Synchronizer" to select the proper clock source.  My
guess is that since the clock isn't running, the flip flops are left in a
weird state.

Or there's another problem here unrelated to the crystal clock.  I guess
I'll see in a day or so.

- Josh

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Tue, Feb 2, 2021 at 12:30 AM Josh Dersch  wrote:

>
>
> On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller  wrote:
>
>>
>>
>> > On Jan 31, 2021, at 8:19 PM, Josh Dersch  wrote:
>> > Well, what's interesting here is that on my system, switch S4 (MAINT
>> STPR) steps the processor with switches S1 and S2 set to *any*
>> configuration.
>>
>> Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1
>> S1:1 step by clock phase.  The other two settings should free run the
>> microcode.  So yeah, sounds like something fishy there...  The TIG card has
>> more than a few analog components, and its not too unusual for these to get
>> hung up on the adjacent card and have a leg pulled or sheared from the
>> board.
>>
>> > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it
>> asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and
>> clears the Timing Generator and the Cache timing."
>>
>> Yup, that's one of the signals coming in to RAC E106.  Probing there
>> should indicate which of possible sources for ZAP is actually occurring
>> (UBCE ROM INIT H on pins 2 and 3 there).
>>
>> DCLO is a classic...  Make sure to 'scope it, because it sometimes has
>> troublesome spikes that don't show on a multimeter.  If you have H742s,
>> there are some wet tantalums on the control board that sometimes leak and
>> cause trouble with this.
>>
>> I'm sure you are raring to go -- hope those fans show up for you
>> tomorrow, and will be interested to hear what you find!
>>
>
>
> Small update; fans arrived today and they are now installed.  Voltages
> tested on the backplane at the points called out in the service docs, and
> all voltages dialed in to 5.05V.  Ripple is within tolerances -- about
> 200mV with some very short spikes that barely show up on my 'scope that go
> to 300mV or so.  Not sure if this is abnormal, I also saw these while
> burning the supplies in on the bench.
>
> Checked the AC LO and DC LO signals at all the points called out in figure
> 6-12 (p. II-6-22 of
> http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
> and appear to be correct.  Looked at most of them under the scope and no
> spikes (other than those in the ripple from the power supply.)
>
> Tomorrow I'll get some boards out on extenders and take a look at what's
> going on at the logic level.
>

Another quick update:  Had some time last night to poke at things.  I
started with the TIG, since I wanted to see if the crystal clock was
running at all and if the right clock source was being selected.  Sure
enough, TIGB XTAL H was a flat line.  Nothing happening at the crystal
itself either.  The crystal's casing was fairly corroded (which is
interesting, since nothing else on the board is) and after a tiny bit of
prodding one of the legs fell off, so I'm hoping that's the culprit.  New
crystal ordered and when it arrives we'll see...

- Josh

Re: Flip-Chip selloff

[Josh Dersch via cctalk]

Since we're talkin' sell-off... on the off chance that anyone has a TC11 or
TC01/08 gathering dust (for something less than eBay prices), I, uh...
could use one.  Along with many other people, I suppose.

- Josh


On Tue, Feb 2, 2021 at 3:12 PM Bill Degnan via cctalk 
wrote:

> I think it's good to hold onto that which is realistic to support, no point
> in holding hardware hostage in a rodent and moisture-vulnerable old
> garage.  We don't live forever.
> b
>
> On Tue, Feb 2, 2021 at 5:57 PM Chris Zach via cctalk <
> cctalk@classiccmp.org>
> wrote:
>
> > What do I have...
> >
> > Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2
> > 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a
> > Minc-11/MiniMINC.
> >
> > Several Perqs, that HP 1000e thing, and a few dozen MFM disks.
> >
> > A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color
> >
> > Probably a lot more.
> >
> > On 2/2/2021 4:13 PM, Bob Smith wrote:
> > > I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two
> > > DECMante II boxes.
> > > bb
> > >
> > > On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk
> > >  wrote:
> > >>
> > >> Might be a good time: I remember my dad saying I should encase each
> one
> > >> in lucite plastic and sell them as paperweights. That was 30 years ago
> > >> but it would have preserved them well :-)
> > >>
> > >> C
> > >> (Went from 3 8/I's to 2 8/L's so progress?)
> > >>
> > >> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote:
> > >>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk <
> > cctalk@classiccmp.org> wrote:
> > 
> >  I don't have any equipment that uses them any more, so I'll be
> > ebaying off my
> >  A-W series flip chips over the next few days. The W's and PT08
> boards
> > are up now
> > 
> >  https://www.ebay.com/itm/184647476832
> >  https://www.ebay.com/itm/184647420812
> > >>>
> > >>> That makes me wonder if I shouldn’t do the same.  That would be part
> > of a camera lens, which may, or may not take up less space. :-)
> > >>>
> > >>> Then again I’ve been saying I need to downsize my collection for the
> > better part of 20 years.
> > >>>
> > >>> Zane
> > >>>
> > >>>
> > >>>
> >
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller  wrote:

>
>
> > On Jan 31, 2021, at 8:19 PM, Josh Dersch  wrote:
> > Well, what's interesting here is that on my system, switch S4 (MAINT
> STPR) steps the processor with switches S1 and S2 set to *any*
> configuration.
>
> Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1
> step by clock phase.  The other two settings should free run the
> microcode.  So yeah, sounds like something fishy there...  The TIG card has
> more than a few analog components, and its not too unusual for these to get
> hung up on the adjacent card and have a leg pulled or sheared from the
> board.
>
> > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it
> asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and
> clears the Timing Generator and the Cache timing."
>
> Yup, that's one of the signals coming in to RAC E106.  Probing there
> should indicate which of possible sources for ZAP is actually occurring
> (UBCE ROM INIT H on pins 2 and 3 there).
>
> DCLO is a classic...  Make sure to 'scope it, because it sometimes has
> troublesome spikes that don't show on a multimeter.  If you have H742s,
> there are some wet tantalums on the control board that sometimes leak and
> cause trouble with this.
>
> I'm sure you are raring to go -- hope those fans show up for you tomorrow,
> and will be interested to hear what you find!
>


Small update; fans arrived today and they are now installed.  Voltages
tested on the backplane at the points called out in the service docs, and
all voltages dialed in to 5.05V.  Ripple is within tolerances -- about
200mV with some very short spikes that barely show up on my 'scope that go
to 300mV or so.  Not sure if this is abnormal, I also saw these while
burning the supplies in on the bench.

Checked the AC LO and DC LO signals at all the points called out in figure
6-12 (p. II-6-22 of
http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
and appear to be correct.  Looked at most of them under the scope and no
spikes (other than those in the ripple from the power supply.)

Tomorrow I'll get some boards out on extenders and take a look at what's
going on at the logic level.

- Josh



>
>   --FritzM.
>
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Sun, Jan 31, 2021 at 7:55 PM Josh Dersch  wrote:

> On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> > Yeah.  I want to get the fans installed and then go triple-check all
>> the power signals and get the voltages dialed in nicely.  But then things
>> come out on extenders :).
>>
>> Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really
>> seems happiest with trimmed up to about 5.1 at the backplane.
>>
>> Looks like E106 on the RAC (M8123) might be a good place to start
>> (drawing RACA, lower left.)
>>
>
> I was just looking in chapter 4 of the processor manual to learn more
> about how the processor clocks are generated on the M8139 (TIG) board; on
> page II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says:
>
> "The third source of timing [the other two being the crystal clock and a
> diagnostic R/C network] is the manually-operated, single-step MAINT STPR
> switch S4, located on the maintenance card.  This switch is only enabled
> when maintenance card switches S2 and S3 are both set to 1."
>
> Section 4.2.3 confirms this:
>
> "The maintenance card S2 and S1 switches are both set to 1 to allow single
> timing pulses to be generated by MAINT STPR switch S4 Removing the S2
> or S1 input conditions the MS EN flip-flop to be cleared."
>
> Well, what's interesting here is that on my system, switch S4 (MAINT STPR)
> steps the processor with switches S1 and S2 set to *any* configuration.
> Tried it with the other KM11 I have, same behavior.  This being the case, I
> wonder if the logic that selects the clock source is faulty, and is always
> selecting the MAINT STPR input.  This would definitely explain the behavior
> I'm seeing.  I hope the fans arrive tomorrow so I can start debugging this
> :).
>

Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it
asserts:

"UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and clears the
Timing Generator and the Cache timing."

I suppose that this is the more likely explanation for the behavior here
and that the maintenance card behavior is a side-effect of this.  Time to
actually probe things, rather than speculating...

- Josh


>
> - Josh
>
>
>>
>> cheers,
>>   --FritzM.
>>
>>
>>
>>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

> > Yeah.  I want to get the fans installed and then go triple-check all the
> power signals and get the voltages dialed in nicely.  But then things come
> out on extenders :).
>
> Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really
> seems happiest with trimmed up to about 5.1 at the backplane.
>
> Looks like E106 on the RAC (M8123) might be a good place to start (drawing
> RACA, lower left.)
>

I was just looking in chapter 4 of the processor manual to learn more about
how the processor clocks are generated on the M8139 (TIG) board; on page
II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says:

"The third source of timing [the other two being the crystal clock and a
diagnostic R/C network] is the manually-operated, single-step MAINT STPR
switch S4, located on the maintenance card.  This switch is only enabled
when maintenance card switches S2 and S3 are both set to 1."

Section 4.2.3 confirms this:

"The maintenance card S2 and S1 switches are both set to 1 to allow single
timing pulses to be generated by MAINT STPR switch S4 Removing the S2
or S1 input conditions the MS EN flip-flop to be cleared."

Well, what's interesting here is that on my system, switch S4 (MAINT STPR)
steps the processor with switches S1 and S2 set to *any* configuration.
Tried it with the other KM11 I have, same behavior.  This being the case, I
wonder if the logic that selects the clock source is faulty, and is always
selecting the MAINT STPR input.  This would definitely explain the behavior
I'm seeing.  I hope the fans arrive tomorrow so I can start debugging this
:).

- Josh


>
> cheers,
>   --FritzM.
>
>
>
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Sun, Jan 31, 2021 at 5:05 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

> Hi Josh,
>
> ZAP is effectively reset for the micro-architecture, forcing the ucode
> address to known/initial value.  It has multiple sources throughout the
> processor, including tendrils into some of trap handling hardware. (Caveat:
> my experience is based off extensive work with the '11/45, but the
> micro-architecture as I understand it for the '11/70 is quite similar.)
>

Yeah, ZAP seems to be the entry point at power-up as well as for trap
handling.


> For the '45, there was a very handy "KB11-A,D Maintenance Manual", which
> explained the logic of such internal signals and the board by board
> internal operation of the CPU to a very useful level of detail; I'm sure
> similar is available for the KB11-B,C?  It's worth a read through if you
> haven't already, though its quite a bit to take in.
>

Yes, there's a similar doc.  The engineering drawings include the flow
diagrams for the microcode, and the Processor Manual (
http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
goes into details on the rest.  I started digesting all of this last night,
it's going to take awhile :).


>
> I would imagine the next step would be to throw the RAC board out on
> extenders, verify that ZAP is asserted, and if so pursue the driving source.
>

Yeah.  I want to get the fans installed and then go triple-check all the
power signals and get the voltages dialed in nicely.  But then things come
out on extenders :).


>
> Do you know if you have a KB11-B or C?
>

It's a KB11-C.


> Happy hunting!
>

Thanks, it'll be interesting for sure.
- Josh


>--FritzM.
>
>
>

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Sun, Jan 31, 2021 at 2:39 PM Guy Sotomayor via cctalk <
cctalk@classiccmp.org> wrote:

> Did you check to make sure that power is wired correctly to the
> PEP-70/Hypercache?  They are typically installed in "empty" slots and
> don't have power (or anything else) routed to them.  They require some
> additional jumpers to be installed on the backplane so that they get power.
>

Yes, it's wired up (Don't know who did the installation, but I'm assuming
it was operational at some point).  There are four large black jumper wires
leading from slot 18 to slot 19, matching the instructions in the PEP70
installation manual.

Thanks,
Josh

PDP-11/70 debugging advice

[Josh Dersch via cctalk]

Hi all --

Making some progress with the "fire sale" PDP-11/70. Over the past month
I've rebuilt the power supplies and burned them in on the bench, and I've
gotten things cleaned up and reassembled.  I'm still waiting on some new
chassis fans but my curiosity overwhelmed my caution and I decided to power
it up for a short time (like 30 seconds) just to see what happens.  Good
news: no smoke or fire.  Voltages look good (need a tiny bit of adjustment
yet) and AC LO and DC LO looked good everywhere I tested them.  Bad news:
processor is almost entirely unresponsive; comes up with the RUN and MASTER
lights on, toggling Halt, and hitting Start causes the RUN light to go out,
but that's the only response I get from the console.

I got out the KM11 boardset and with that installed I can step through
microinstructions and it's definitely executing them, and seems to be
following the flow diagrams in the engineering drawings.  Left to its own
devices, however, the processor doesn't seem to be executing
microinstructions at all, it's stuck at uAddress 200.

In the troubleshooting section of the 11/70 service docs (diagram on p.
5-16) it states:

IF LOAD ADRS DOES NOT WORK AND:
- RUN, MASTER & ALL DATA INDICATORS ARE ON
- uADRS = 200 (ZAP)
THEN MEMORY HAS LOST POWER

Which seems to adequately describe the symptoms I'm seeing, but as far as I
can tell the AC and DC LO signals are all fine.  (This system has a Setasi
PEP70/Hypercache installed, so there's no separate memory chassis to worry
about.)  I'm going to go back and re-check everything, but I was curious if
anyone knows whether loss of AC or DC would prevent the processor from
executing microcode -- from everything I understand it should cause a trap,
and I don't see anything in the docs about inhibiting microcode execution.
But perhaps if this happens at power-up things behave differently?  And the
fact that the troubleshooting flowchart calls out these exact symptoms
would seem to indicate that this is expected.  But I'm curious why the KM11
can step the processor, in this case.

I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday)
before I poke at this again, just looking for advice here on the off chance
anyone's seen this behavior before.

Thanks as always!
- Josh

Re: PDP-11/70 backplane wire list

[Josh Dersch via cctalk]

On Fri, Jan 1, 2021 at 10:06 PM Eric Smith  wrote:

> On Fri, Jan 1, 2021 at 10:04 PM Josh Dersch via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Discovered a broken wirewrap wire on the 11/70 I'm slowly working on, it's
>> on the last slot (44), and runs from BD2 to ??.  White wire, part of a
>> white/black twisted pair.  I've been looking but haven't found a wire list
>> for the backplane
>>
>
> There would be two different 11/70 backplane wirelists, depending on
> whether your CPU is a KB11-B or a KB11-C. Unfortunately I don't have either
> wirelist.
>

> If your 11/70 has an M8133 and an M8138, it's a KB11-B.
> If it has an MB8123 and MB8138-YA, it's a KB11-C.
>

I have a KB11-C here.


> You're undoubtedly aware that the A/B section of slot 44 is for the Unibus
> cable or terminator, so BD2 is signal BR4 L. It should probably go to the
> BR4 L pin of the slot 44 SPC, which would be pin DH2, which would be bussed
> through DH2 of the other SPC slots (40-43).
>

You know, that really should have occurred to me.  Convenient that the
break happened on such a convenient pin!

Thanks for the tip, I'll double-check everything tomorrow and see if I can
find my wire-wrap tool...

- Josh



>
> RH70 Massbus controllers normally use BR5 L, but I suspect that the BR4 L
> line would be wired to their slots as well. I don't have an RH70 print set,
> so I don't know the details. From the RH70s (or slot 40, if BR4 L doesn't
> go to the RH70s), I would expect it to go to the Trap & Msc Control board
> (TMCB) in slot 11, pin FP1.
>
> Best regards,
> Eric
>
>

PDP-11/70 backplane wire list

[Josh Dersch via cctalk]

Hey all --

Discovered a broken wirewrap wire on the 11/70 I'm slowly working on, it's
on the last slot (44), and runs from BD2 to ??.  White wire, part of a
white/black twisted pair.  I've been looking but haven't found a wire list
for the backplane -- anyone have any leads, or, alternately, does anyone
have ready access to an 11/70 backplane to trace where the wire from BD2 on
slot 44 goes to?  (Fortunately it looks like there's just the one wire on
that pin, though there might be one "below" it on the pin that I can't
quite see, rather cramped in there.)

Thanks as always,
Josh

Re: Hey, I got a Perq_T2 image!!!

[Josh Dersch via cctalk]

On Thu, Dec 31, 2020 at 12:20 PM Chris Zach via cctalk <
cctalk@classiccmp.org> wrote:

> Well, after waiting almost a month for the USPS to deliver a "Priority
> Mail 1 day" package from Dave I now have the MFM reader card. So I
> started working on these disks I rescued. First up was a ST506 (labelled
> "RD50" by DEC) and a pair of ST412's.
>
> Bad news: No drives spun up
> Good news: You can take the controller board off the drives and spin the
> spindles by hand.
> Better news: The spindles spun (clockwise, viewed from bottom)
> Best news: spinning while powering on got all three to spin up.
>

Congrats!


> So far I imaged the RD50 (possibly a Rainbow or a Pro/350) and one of
> the ST412's. It came up as a PERQ_T2 format and I have two dumps of the
> disk with only one bad sector reported.
>
> Anyone know what to do with this kind of image? I've powered down the
> drives and will store them till I can figure out how to make them run
> more quietly
>

I'd love a copy of the T2 image, and if it has POS filesystems on it I
should be able to extract files.  Regardless I should be able to boot it on
my T2 to find out what's on it...

- Josh


>
> C
>

Re: ISO: TI 980 (not 980A or 980B) Hardware docs

[Josh Dersch via cctalk]

On Wed, Dec 30, 2020 at 1:53 AM osi.superboard via cctalk <
cctalk@classiccmp.org> wrote:

> Hi Josh,
>
> maybe this helps
>
>
> https://pic2.avaluer.org/imgspic/a/r/k/m/r/-vintage_ti_980_ttl_based_minicomputer_w_1103_ram_boards_texas_instruments-3_27.jpg


Thanks.  That looks like a 980B to me.  Here's a couple of pictures of what
I have (note that the boards are placed mostly randomly right now, just for
safekeeping):

https://1drv.ms/u/s!Aqb36sqnCIfMpJFO9udIaPHKbzS5bg?e=L7RxCk

- Josh



>
>
> Thomas
>
> Am 30.12.2020 um 01:23 schrieb Josh Dersch via cctalk:
> > Hey all --
> >
> > A straight TI 980 (not one of the later 980A or 980B variants) appeared
> on
> > my doorstep this afternoon.  While well-shipped, the person I got it from
> > decided to ship the boards and power supply separately from the chassis
> --
> > and unfortunately didn't document where anything goes.
> >
> > There is precious little information out there about the original 980 --
> > anyone sitting on any documentation?  Anyone know someone who has one?
> > (Anyone have any spare parts? The core memory boards & chassis are
> labeled
> > well enough for me to see that I'm missing one of the "DA" boards...)
> >
> > Thanks,
> > Josh
>

Re: ISO: TI 980 (not 980A or 980B) Hardware docs

[Josh Dersch via cctalk]

On Wed, Dec 30, 2020 at 2:07 AM Ethan Dicks  wrote:

> On Tue, Dec 29, 2020 at 8:23 PM Josh Dersch via cctalk
>  wrote:
> > A straight TI 980 (not one of the later 980A or 980B variants) appeared
> on
> > my doorstep this afternoon.
>
> Interesting.  Unfortunately, I have no docs (outside of what's on
> Bitsavers).
>
> Mine is the later 980A variety, FWIW, with fat TI4060 DRAMs not core.
> I only recently got a console key for it.
>
> > (Anyone have any spare parts? The core memory boards & chassis are
> labeled
> > well enough for me to see that I'm missing one of the "DA" boards...)
>
> The only spare parts would be some memory boards.  I'll have to pull
> them out and check them, but definitely DRAM and I think 8K or 24K
> capacity, and I have no idea if they work on all variants or just
> specific models.  No spare I/O or CPU boards.
>

I'd be interested to see pictures of the card cages.  I know what a 980B
looks like and it's a significant revision from the 980 I have here -- the
CPU is condensed from 13 or 14 boards down to four or so.  I haven't been
able to find a picture of the 980A's insides, curious to know how it
differs.


>
> I was just glancing over at the docs on Bitsavers to see what it might
> take to write a memory tester to toggle in.  Nothing exhaustive just
> simple write-read-compare testing.  I know nothing of the architecture
> so even that would take me a bit to figure out.
>
> http://www.bitsavers.org/pdf/ti/980/


Somewhere I have a couple of very short programs I hand-assembled to test
out my 980B, I'll see if I can't dig them up... I suspect I left them on my
old laptop.

Thanks,
- Josh


>
>
> -ethan
>

ISO: TI 980 (not 980A or 980B) Hardware docs

[Josh Dersch via cctalk]

Hey all --

A straight TI 980 (not one of the later 980A or 980B variants) appeared on
my doorstep this afternoon.  While well-shipped, the person I got it from
decided to ship the boards and power supply separately from the chassis --
and unfortunately didn't document where anything goes.

There is precious little information out there about the original 980 --
anyone sitting on any documentation?  Anyone know someone who has one?
(Anyone have any spare parts? The core memory boards & chassis are labeled
well enough for me to see that I'm missing one of the "DA" boards...)

Thanks,
Josh

Re: RL02 Tracking

[Josh Dersch via cctalk]

On Mon, Dec 21, 2020 at 3:09 PM Jon Elson via cctalk 
wrote:

> On 12/21/2020 01:08 PM, Aaron Jackson via cctalk wrote:
> > Hi everyone
> >
> > I've posted a few times over the years about RL02 drives and my
> > difficulty getting them working (no luck so far!). I've spent the past
> > few days working on one of them and have made some progress.
> >
> > The status currently is that the heads will load, and the ready lamp
> > flashes as the heads wobble back and forth very slightly,
> I dropped an RL02 cartridge, and needed to get it to load
> one more time to get programs off it.
> The ready lamp was a dim, slightly flickering glow.  I
> figured the platter had been knocked off center.
> I loosened the bolts at tapped it a bit until it looked
> better centered.  It took a couple tries, but then the ready
> light came on fully bright, and I was able to mount the disk
> and read it.
>
> I don't know if that could be your problem.  If you get a
> solid servo signal with the motor disconnected, then this is
> not the same problem.
>

To add my two cents, I've also seen this behavior on RL02 packs that have
been degaussed.  It might be worth your time to find someone with a known
working RL02 drive (or known working RL02 pack) so you can confirm that
your packs are good.

- Josh



>
> Jon
>

Re: Ouch, but 2 Perqs out.

[Josh Dersch via cctalk]

On Sat, Dec 12, 2020 at 6:31 PM Chris Zach  wrote:

> > DigiBarn has a few pictures of a PERQ 1 and a T2:
> >
> > http://www.digibarn.com/collections/systems/perqt2/index.html
>
> Yep, the 1 is out, and one of the other two is a T2 like the picture.
>
> > There's the rarer PERQ 2, which I have a picture of here:
>
> Hm. The other one does not look like that, it is similar in shape to the
> T2 but it's a different shape and says ICL on the front. I grabbed both
> of the front panels because they were accessible, will post pics in a bit.
>

Something like this, then?

http://www.computinghistory.org.uk/det/17020/ICL-PERQ-2-T1-Workstation/

A bit more uncommon over here, I think...



> > If you pull the side, front, and rear panels off (be careful there --
> > the drives are mounted to the rear, and there are cables to deal with),
> > and pull the boards, it should be significantly lighter.
>
> Ok. Next time I go over I'll see if I can at least uncover one. Maybe I
> can stack the Sun gear where the Perq1 was.
>
> > Sounds like the newer-style portrait monitor for the PERQ 2 to me.
>
> Yeah, it reminded me of that 66 line terminal people had in the early
> 80's. It was up and down, not side to side, were the other monitors
> landscape only?
>

The PERQ 1 was originally portrait, there were landscape options later on,
which became more prevalent with the T1 and T2 models.


>
> And a big DB style plug to go into the computer.
>
> > It varies.  See the Digibarn T2 pictures for one example; the
> > Summagraphics Bit Pad One was another common option -- big white tablet
> > about 15" square with a 4-button wired puck.  GPIB interface.  There was
> > also the Kriz tablet which was smaller and had three buttons.
>
> Ok, there are a lot of junk sun keyboards and mice in there and it's a
> mess with all the general crud. What does the plug going to the Perq
> look like? Are they optical or mechanical?
>

Neither.  Electromagnetic :).  The Bit Pad One has a GPIB cable (which on
the T2 and maybe the T1 is a DB15), the Kriz tablet used a DB15 (IIRC).


>
>
> > Looking forward to pictures!
>
> I'll post some in a bit. Not very good ones, but best we can do.
>

Cool!

 - Josh


> Chris
>

Re: Ouch, but 2 Perqs out.

[Josh Dersch via cctalk]

On Sat, Dec 12, 2020 at 2:56 PM Chris Zach via cctalk 
wrote:

> This was a long day. Went over to the house and started working on
> getting the Perqs out of the basement. I've been moving smaller stuff to
> make room and it was time.
>
> First up was a Perq1 chassis that just had the big disk drive in it,
> side and rear panels. I figured it was lightest and after taking off the
> sides and top was able to lift it and carry it up steps. Still heavy and
> bulky, but it made room and a path to get to the second one.
>
> The second one was a mess but a lot heavier: It still had the card cage
> in it and I was not going to be able to lift. So I figured out how to
> take the sides, top, front, back, and bottom (pounds are made of ounces)
> and then spottted the screws that hold the card cage and power supply in
> the box. Bless the people at perq, those two screws out and you can lift
> the cage out the side of the box.
>
> The card cage without cards (took them out to lighten) was heavy but I
> got it up the steps. Then with a herculean amount of effort I managed to
> carry the rest of the box up, followed by the sides, top, front, back,
> and bottom plates.
>
> There are still two more Perqs down there. They have heavier front
> plates (I was able to take them off) with real shielding. They were
> different designs, so they were not Perq1s and they are not the same as
> each other.
>
> Question: Are there any pictures of other types of Perqs?
>

DigiBarn has a few pictures of a PERQ 1 and a T2:

http://www.digibarn.com/collections/systems/perqt2/index.html

There's the rarer PERQ 2, which I have a picture of here:

https://1drv.ms/u/s!Aqb36sqnCIfMo9970DK9zAIhDnnUjg


>
> Unfortunately they are still buried under old Sun gear and a Vaxserver
> of some sort. So I'll have to think about those, but they will need to
> come apart as well.
>
> Question: Do the card cages and stuff come off the later Perqs as well?
>

Not as easily.  They can all be disassembled to a point but it's not nearly
as simple as the PERQ 1/1A.

If you pull the side, front, and rear panels off (be careful there -- the
drives are mounted to the rear, and there are cables to deal with), and
pull the boards, it should be significantly lighter.


>
> Also got two different types of keyboards that say Perq, and a monitor
> that looks like a big fat white Vetrex and says Three Rivers.
>

Sounds like the newer-style portrait monitor for the PERQ 2 to me.


>
> Question: What does a Perq mouse look like?
>

It varies.  See the Digibarn T2 pictures for one example; the Summagraphics
Bit Pad One was another common option -- big white tablet about 15" square
with a 4-button wired puck.  GPIB interface.  There was also the Kriz
tablet which was smaller and had three buttons.


>
> At least this stuff will not be junked. I'll take pictures and such
> tomorrow and throw a tarp over everything tonight because I'm too tired
> to get it out of the truck.
>

Looking forward to pictures!

- Josh


> I swore off high-mass hobbies for a reason
>

Re: Fire-Sale PDP-11 update (and request for parts)

[Josh Dersch via cctalk]

On Sun, Dec 6, 2020 at 3:11 PM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Dec 4, 2020, at 10:41 PM, Josh Dersch via cctalk <
> cctalk@classiccmp.org> wrote:
> > I realize this is unlikely, but I was curious if anyone has 1) any
> > parts of the 11/45 power wiring harness...  I can build my own wiring
> harness, but if I can save
> > myself the trouble, that'd be nice.
>
> Yeah, I had build my own for my /45 restoration.  It wasn't all that bad.
> Throw down for a nice ratcheting single-gesture crimp tool for the job and
> you'll be glad that you did :-)
>
> I found wirebarn.com had a nice selection of wire available in
> less-than-full-spool lengths, and most of the original colors.  I may have
> had to fill in a few things from other suppliers (I found it helpful to
> stick to the original color coding.)
>

Thanks, that'll be handy.


>
> Another tip is that the wire list you see in most of the /45 drawing sets
> is actually for the power harness, and not the backplane.  The wire lengths
> in that list were useful; I cut to those lengths, then started on the
> regulator side of the harness, installed in the machine, and bundled and
> trimmed to length as I worked my way down the backplane.  In the end I had
> a reasonably neat fit and very little wasted wire.
>

Also very good to know, thanks!


>
> I had the extra wrinkle of having the earlier (serial # <2000) power
> distribution system in my /45 (IIRC the wire list was from the newer
> system, but it wasn't too hard to adapt it.)
>
> Do you have the springy steel strip that supports the harness between the
> moving and stationary parts of the cabinet?  That may require some fab or
> improvisation if not.  I had one left over from an 11/40 that I was able to
> make work well enough with my older style cabinet.
>

I do, it's a bit rusty.  What remains of the wiring harness is no longer
attached to it, as the plastic ties holding it in place burned away (along
with the rubber sheathing and the most of insulation on the wires
themselves.)

- Josh


>
>cheers,
>  --FritzM.
>
>
>

Re: Problems with FORT and ALGOL in TSS/8

[Josh Dersch via cctalk]

On Thu, Dec 3, 2020 at 9:38 PM Josh Dersch  wrote:

> On Thu, Dec 3, 2020 at 6:13 PM Kevin Jordan via cctalk <
> cctalk@classiccmp.org> wrote:
>
>>
>>
>> Specifically, in the case of FORTRAN, the compiler exits with an error
>> code
>> 6204. This occurs even when trying to compile trivial "hello world"
>> programs, and it appears to occur in all other TSS/8 distributions we've
>> tried as well (i.e., this particular problem is not unique to the LCM+L
>> distribution). We haven't found error code 6204 specifically documented in
>> the TSS/8 user/admin manuals, but the manuals do document other error
>> codes
>> in the 62xx range. Documented error codes in the 62xx range appear to
>> reflect file I/O errors, so we're wondering if perhaps one of the files
>> supporting the FORTRAN compiler is corrupt in all of these distributions.
>>
>
> The LCM+L variant is built starting from the same disk image as all the
> other TSS/8 systems out there (which was originally taken from John
> Wilson's TSS/8 system).  I extended the filesystem to a full megaword (the
> maximum supported by TSS/8) for the RK05 image.
>
> I suspect you may be right that FORTRAN is corrupted, I'll take a look
> this weekend.  I'll admit to not having played with it; though I did test
> out everything else.
>

Finally had a chance to look at this.  The 6204 error message is documented
in the EDUSYSTEM 50 guide here:

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/tss8/DEC-08-E50UA-A-D_UG_Aug75.pdf

See page 6-49:

"6204 Error in reading the compiler, FDCOMP.  Must be stored under
account 2."

And yes, the library account (2) is missing FDCOMP.SAV, and I know of no
existing copy of this code anywhere, unfortunately.  Perhaps it will turn
up somewhere someday, on a DECtape gathering dust on someone's shelf.  I
really do wish more TSS/8 stuff was out there, but I suppose we should be
thankful that any of it survived.

- Josh

Re: Help needed identifying old MFM drives from the excavation

[Josh Dersch via cctalk]

On Tue, Dec 8, 2020 at 3:23 PM Chris Zach via cctalk 
wrote:

> Good news: I'm going to get a reader on loan so I should be able to
> image these things. I'll put them up on my web server here, if anyone
> would like to take a look at them let me know.
>
> On a positive note it looks like the Perq T2 units used either the ST506
> or ST412 drives, so those *might* have Perq data as I don't think Bob
> ever had a Pro/350. Then again could be rainbows, is there a PERQ
> emulator out on the web or does anyone know what a Perq disk would look
> like?
>

David's MFM emulator knows how to decode PERQ hard drive images, if you use
the "--analyze" option to "mfm_read" it should pick it up.  I have a hacky
utility that can extract files from disk images, if they're in POS format.

As for emulators, yes, the one I wrote ages ago, but it doesn't emulate the
T2, as much as I keep hoping to get back to it and make that happen...
https://github.com/jdersch/PERQemu

- Josh

Re: Help needed identifying old MFM drives from the excavation

[Josh Dersch via cctalk]

On Sun, Dec 6, 2020 at 7:34 PM Chris Zach  wrote:

> > I'd suspect that at least a few of these were from PERQ systems, given
> > their provenance.  Vertex V150s and Miniscribes were commonly used in
> > the T2 models.  As another listmember mentioned, Dave Gesswein's MFM
> > emulator will image these (and can decode PERQ hard drive formats.)
>
> Probably. I didn't realize Perqs used reasonable sized drives, there's a
> box there I've dug out with what looks like a transparent 8 inch drive
> that I will try to disassemble and get up the stairs next time. Think
> "dungeon" and "Y2" class steps
>

Yeah, the later models used 5.25" media; the rare PERQ 2 used 8" Micropolis
drives, and the PERQ 1/1A used 14" Shugart SA-4000 drives.


>
> > (If you do manage to capture PERQ images, please let me know...)
>
> Absolutely. I have yet more Perq manuals as well and floppies. Did Perqs
> only use 8 inch disks or should I keep eyes out for 5.25 as well?
>

8" floppy media exclusively.


>
> https://i.imgur.com/ohuohvC.jpg


That's a 14" Shugart SA-4000, given that it came from Bob's basement,
definitely a PERQ disk.  Tough to read without a PERQ but there may be some
options nearby you, if you manage to extract it from the basement.  Make
sure the spindle and heads are parked before moving.

- Josh



>
>
> Chris
>

Re: Help needed identifying old MFM drives from the excavation

[Josh Dersch via cctalk]

On Sun, Dec 6, 2020 at 6:25 PM Chris Zach via cctalk 
wrote:

> As the excavation of Bob's junkpile continues I have finally hit the MFM
> layer. Specifically about 10 5.25 hard disks that look to be old style
> MFM drives.
>
> Vertex V150
> Miniscribe 6085
> ST 4038M Seagate Franklin telecom AT-40
> Miniscribe 3650 HH
> Seagate ST4096
> Priam ID45-H
> Rodime RO203E
> RD54
> Real ST506
> Pair of ST412's.
>
> Anyone recognize what kinds of systems may have used these? The RD54 is
> of course DEC, and I'm guessing the ST506 and 412's were from either a
> Rainbow or a Professional/350. But the rest are weird. Maybe Convergent
> miniframes? Probably not PC's as Bob had a lot of weird stuff.
>

I'd suspect that at least a few of these were from PERQ systems, given
their provenance.  Vertex V150s and Miniscribes were commonly used in the
T2 models.  As another listmember mentioned, Dave Gesswein's MFM emulator
will image these (and can decode PERQ hard drive formats.)

(If you do manage to capture PERQ images, please let me know...)

- Josh

Fire-Sale PDP-11 update (and request for parts)

[Josh Dersch via cctalk]

Thought you folks might be interested in a quick update on my folly here.

At the beginning of November I drove down to the bay area to pick up the
two fire-damaged PDP-11 systems -- a PDP-11/70 and a PDP-11/45.  (I also
made a few other stops and got a few other items, but that's not what I'm
here to talk about...)

Over the past few weeks I've gone over the two systems and my assessment is
that the 11/70, while completely filthy, is completely restorable.  The
fire/heat damaged the front panel enough to discolor the plexi and start
melting a few switches (http://yahozna.dyndns.org/scratch/1170/1170.jpg)
but that's the extent of the damage.  My only fear is that the fingers on
the backplanes might possibly have some corrosion here and there, but I've
started going through and cleaning the boards and the backplane slots and
so far I haven't run into anything that looks troubling.

The 11/45 is considerably further gone.  It took a serious amount of heat,
enough for the pig iron frame for the front panel to start melting (
http://yahozna.dyndns.org/scratch/1170/1145.jpg).  The front panel is
completely destroyed, as is the wiring harness for the power distribution.
But... the metal of the chassis and the power supplies seems to have
protected the boards and the backplane.  There are no melted or even
discolored wire-wrap wires on the backplane, and the boards look fine.  As
an experiment I took the non-11/45-specific boards out of the backplane (a
Plessey memory board, an RL11 controller, and an M9301 bootstrap terminator
-- this one was right up front where things were the hottest and the
handles had started to melt) and tested them in my PDP-11/40.  They all
work fine.  So I think that, maybe, with a LOT of effort, the 11/45 could
live again.

I'm tackling the 11/70 first (Al kindly sold me a new front panel for a
very reasonable price so it already looks 100% better) and once I'm done
with that I hope to move on to the 11/45.  In the meantime I'm hoping to
keep my eyes peeled for parts for the /45.  I found a seller on eBay with
"restored" H7420a power supplies for $68, with free shipping so I grabbed a
pair.  I realize this is unlikely, but I was curious if anyone has 1) any
parts of the 11/45 power wiring harness, or 2) (really unlikely) an 11/45
front panel in any condition.  Well, any condition better than "melted into
slag," I suppose.  I can build my own wiring harness, but if I can save
myself the trouble, that'd be nice.

- Josh

Re: Problems with FORT and ALGOL in TSS/8

[Josh Dersch via cctalk]

On Thu, Dec 3, 2020 at 6:13 PM Kevin Jordan via cctalk <
cctalk@classiccmp.org> wrote:

> Hi everyone,
>
> The Nostalgic Computing Center  has a
> virtual PDP-8 running TSS/8
> <
> http://www.nostalgiccomputing.org:8080/aterm.html?m=pdp8=PDP-8=24=80
> >
> in its collection. We use the SIMH PDP-8e emulator to support the machine,
> and we recently updated the machine to run the TSS/8 distribution created
> by LCM+L, found here on GitHub
> . The LCM+L
> distribution
> is slightly different from other TSS/8 distributions available on the web
> in that it provides some additional goodies such as ALGOL and LISP.
>
> The NCC demonstrates how various classic computers worked by providing
> automated scripts that interact with the machines in the collection.
> For example, to demonstrate each of the programming languages supported by
> a machine, scripts are provided to create, compile, and run a simple
> Fibonacci sequence generator. We've done this for the TSS/8 system, but the
> scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone
> on this list might know why.
>
> Specifically, in the case of FORTRAN, the compiler exits with an error code
> 6204. This occurs even when trying to compile trivial "hello world"
> programs, and it appears to occur in all other TSS/8 distributions we've
> tried as well (i.e., this particular problem is not unique to the LCM+L
> distribution). We haven't found error code 6204 specifically documented in
> the TSS/8 user/admin manuals, but the manuals do document other error codes
> in the 62xx range. Documented error codes in the 62xx range appear to
> reflect file I/O errors, so we're wondering if perhaps one of the files
> supporting the FORTRAN compiler is corrupt in all of these distributions.
>

The LCM+L variant is built starting from the same disk image as all the
other TSS/8 systems out there (which was originally taken from John
Wilson's TSS/8 system).  I extended the filesystem to a full megaword (the
maximum supported by TSS/8) for the RK05 image.

I suspect you may be right that FORTRAN is corrupted, I'll take a look this
weekend.  I'll admit to not having played with it; though I did test out
everything else.


>
> For example, here is a transcription of a simple session demonstrating the
> problem:
>
>



>
> Note that BASIC, FOCAL, and LISP all seem to run very nicely on the
> machine.
>
> The problem we're experiencing with ALGOL appears to be a glaring compiler
> bug, but the compiler was distributed widely through DECUS, and it is
> difficult to imagine that it would have been released with an obvious bug,
>

I don't know if that's an accurate statement.  Have you looked at Appendix
E of the manual?  There are a ton of errata there.  For example, on page
E-2:

"Boolean operator 'AND' does not function properly at all times for example:
 T = true
 F = false
 T 'AND' T -> T Correct
 T 'AND' F -> T Wrong, should be F
 F 'AND' T -> T Wrong, should be F"

The TSS/8 version of ALGOL fixes this bug but there are others.  A friend
of mine recently spent an evening trying to get a small ALGOL program to
compile and run on my online TSS/8 system and failed utterly; after a lot
of effort it finally compiles, but produces no output when run and we're
both pretty stumped about it.  We suspect that this compiler just has a lot
of bugs.

Note also that Appendix E (page E-1) suggests that ALL 'END' statements be
followed by a ";".  This seemed to help at least with getting the compiler
to stop giving us errors.  Note that despite this suggestion, the examples
in Appendix E fail to follow this guideline.

- Josh

Re: Anyone want some LMI Lisp Machine tapes?

[Josh Dersch via cctalk]

On Wed, Dec 2, 2020 at 10:20 AM Liam Proven via cctalk <
cctalk@classiccmp.org> wrote:

> https://www.ebay.de/itm/254795423667
>
> €1
>
> «
> LISP MACHINE INC 1/2" Reel Tapes
>
> Anyone who opens this auction will know what this is - and how unique
> these tapes are.
>
> The lot is consisting of 13 tapes, which are labeled as follows:
>
> LMI FORTRAN 77 #1352- LMI Release 2.0 two tapes
> LMI Boot / SDU 3.14 #3143- Rev A
> LMI REL 3.1 Patch Tape 1600BPI 30. SEP 1987
> LMI CS Tape Experimental 6. AUG 1987
> LMI UCODE 1599 11 FEB 1987
> LMI RELEASE 2.0 Diagnostics #1022-
> LMI LISP SOURCE
> LMI Release 3.0 LISP System 3.205 Microcode 1593
>
> plus four unlabeled tapes
> plus two loose tape label, not assignable to the tapes unlabled
>
> The tapes were not tested for readability by me and will be sold as is.
>
> Shipment world wide, please ask for shipment costs - additional
> insurance cost might be apply.
> »
>

I was going to try to get these and image them.  I still have a few other
Lambda tapes to image that came with my system, but they need a good baking
first...

- Josh



>
> --
> Liam Proven – Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
> Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
> UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
>

ISO: Keronix Omnibus 8K "E1" memory schematics / technical docs

[Josh Dersch via cctalk]

Hey all --

Got a nice 8KW omnibus core memory board here, designated the "E1" from
Keronix, that almost works except that bit 1 is off in the weeds
somewhere.  Not a lot of information out there on Keronix hardware, anyone
have any docs?  The board came with a sheet describing the addressing
configuration, but that's it.

Thanks as always,
Josh

Re: FIRE SALE!

[Josh Dersch via cctalk]

On Sun, Oct 11, 2020 at 8:13 PM jim stephens via cctalk <
cctalk@classiccmp.org> wrote:

>
> I agree.  Most devices are expected to be heated briefly to soldering
> temperatures, not heat soaked at that.
>
> Temperature in this case is much different than heat.  The designers of
> the devices must take into account what temperature is require to do the
> solder assembly function, and minimize the amount of heat the device is
> exposed to.
>
> On wave soldering machines the heat was quite low, and these would have
> been assembled then.  Even with current radiant oven techniques, the
> parts would fall off if there was an extended heat exposure.  They do
> that often enough now with heating problems with devices, with open
> circuit failures happening.
>
> If you're lucky and have a quick fire department response, the setup
> time on the equipment is at least 4 or 5 minutes.  Unless there's
> physical danger and the building involved may have people trapped, they
> take time to assess the fire, the propagation and there's more time
> before they attack.
>
> I've seen a couple of events and a couple of full exercises, it doesn't
> happen quickly.  Fire departments are sadly known for letting buildings
> burn into the basement if it saves life or property of other nearby
> structures.  You'd be lucky to get this out of a burned out building in
> most cases.  Once the fire is knocked down the heat will be present for
> quite some time afterwards, as they let it cool and clear flash fires,
> and take care of nearby property.
>
> thanks
> jim
>


Well, we'll see how bad these things really are.  The idiot I am, I struck
what I consider to be a reasonable deal for the 11/70 and 11/45 and I'll be
picking them up in November on a trip to SF I already had planned.  What
can I say, I'm a glutton for punishment.

A friend of mine went out and ot a number of decent high-res pictures of
the units.  The backplanes/wirewrap don't appear to be physically damaged,
and the boards inside look pretty decent, though I'm not holding my
breath.  (I was particularly surprised that none of the pot-metal card
stiffeners were warped or bent due to the heat, even near the front on the
11/45 where it's clear most of the heat was present.)  I do have a friend
with a spare set of 11/70 boards.  What sold me though was that the 11/70
has a PEP70 + Hypercache board set installed (which would be really cool,
assuming anything in there can be made to work again).

I figure worst case, I get a couple of DEC racks that'll work fine after
some sanding and repainting, and maybe I can send the chassis off to Ethan
if repair turns out to be impossible.

- Josh

Re: Identifying mystery TI ICs (Motorola MDP-1000 investigation continues...)

[Josh Dersch via cctalk]

On Sun, Oct 4, 2020 at 11:42 AM Josh Dersch  wrote:

> On Sun, Oct 4, 2020 at 10:26 AM Brent Hilpert via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> On 2020-Oct-04, at 1:22 AM, Josh Dersch via cctalk wrote:
>>
>> > More mysteries while poking at the MDP-1000.  Spent some time this
>> evening
>> > working out the rest of the signals on the power harness (I suspect
>> inputs
>> > for an LTC circuit and a "power good" signal, as well as something
>> > connected to a relay on the backplane, probably related to power
>> control).
>> >
>> > There are a lot of unidentifiable ICs on the main CPU logic board and on
>> > the backplane, mixed in with bog-standard 7400-series TTL.  Curious if
>> > anyone has any ideas, as my searches and perusal of
>> datasheets/databooks on
>> > Bitsavers have turned up nothing.  These are all TI-manufactured ICs,
>> 1969
>> > manufacturing dates, with "SN48xx" and "SN63xx" part numbers (a few omit
>> > the "SN" prefix.)  I'm wondering if these are just standard 7400 ICs
>> with
>> > special codes; for example there are several SN4816's near the edge
>> > connector for the I/O bus, where a 7416 might (?) make sense, and from
>> some
>> > basic probing and following traces I think the pinouts make sense.
>> > (Everything's conformal coated so it's a real bear to beep things
>> out...)
>> >
>> > Any ideas?
>>
>> I have run across TI ICs from that era with odd/unknown series numbering,
>> in particular the SN3900 and SN4500 DTL ICs.
>> Notably:
>> - by pinout they match up with standard DTL series ICs,
>> - I have only found these in equipment from one manufacturer:
>> calculators built by Canon.
>>
>> I received a solitary page of datasheet for some of them (by way of a
>> Canon service center many years ago), but I have never seen them mentioned
>> in TI databooks from the era, even in those sections where they list e.g.
>> "other products from TI" and proceed to list little known series and part
>> numbers.
>>
>> So an obvious guess is these were house numbering systems of standard
>> parts done for the purchaser/equipment manufacturer but with TI's format
>> scheme rather than a format specified by the manufacturer. Another guess
>> would be standard parts tested and selected for purchaser-specified
>> parameters, although that seems a little excessive for these cases.
>>
>
> Yeah, either of those options seems a likely possibility.  It definitely
> seems like they were building this thing for bulletproof operation, so
> maybe it really is the latter.
>
>
>>
>> The 54/7400 series originated with TI in 65, I'm not aware of them
>> producing any other TTL series, other than perhaps second-sourcing some
>> other manufacturer's.
>> I guess that's another possibility - another manuf's TTL series, labeled
>> differently.
>>
>> Odd that this Motorola CPU is filled with ICs manufactured by TI.
>>
>
> Yeah, the irony of this was not lost on me.  Other than the aforementioned
> linear ICs in the core modules, every IC in this has a TI logo on it.
>
>
>>
>> It's conceivable, although it seems less probable, that they're DTL
>> rather than TTL.
>>
>> On the whole, best guess would seem to be 7400-series inside.
>>
>
> Yeah, I'm guessing (hoping) 7400 as well, especially since there are
> actual 74xx-labeled ICs in here casually mixed with the 48xx and 63xx.
>
> A thought occurred, that if I get desperate I could remove a few of the
> ICs and attempt identification using the IC tester I have.  Not going to do
> that unless I can't figure it out any other way.  The good news is there
> aren't too many varieties.  I haven't done a full inventory but there's not
> more than a dozen or so different types in here.
>
>
>>
>> --
>>
>> On another issue, did you trace the +/-15V lines to the core
>> address/inhibit drivers?
>> Could some of the remaining wires from the PS be other core supplies -
>> 15V was a little low compared to most core systems I've seen.
>>
>>
> I did manage to trace the +/-15V lines to the drivers on the core memory.
> I don't believe any of the extra signals are other voltages -- three of
> them go to the CPU board, one goes to the aforementioned mystery relay, one
> goes to a tiny bit of logic on the mainboard (I suspect some manner of
> LTC), and the last goes to a trace that just dead-ends and goes nowhere at
> all.  The very little docu

Re: Identifying mystery TI ICs (Motorola MDP-1000 investigation continues...)

[Josh Dersch via cctalk]

On Sun, Oct 4, 2020 at 10:26 AM Brent Hilpert via cctalk <
cctalk@classiccmp.org> wrote:

> On 2020-Oct-04, at 1:22 AM, Josh Dersch via cctalk wrote:
>
> > More mysteries while poking at the MDP-1000.  Spent some time this
> evening
> > working out the rest of the signals on the power harness (I suspect
> inputs
> > for an LTC circuit and a "power good" signal, as well as something
> > connected to a relay on the backplane, probably related to power
> control).
> >
> > There are a lot of unidentifiable ICs on the main CPU logic board and on
> > the backplane, mixed in with bog-standard 7400-series TTL.  Curious if
> > anyone has any ideas, as my searches and perusal of datasheets/databooks
> on
> > Bitsavers have turned up nothing.  These are all TI-manufactured ICs,
> 1969
> > manufacturing dates, with "SN48xx" and "SN63xx" part numbers (a few omit
> > the "SN" prefix.)  I'm wondering if these are just standard 7400 ICs with
> > special codes; for example there are several SN4816's near the edge
> > connector for the I/O bus, where a 7416 might (?) make sense, and from
> some
> > basic probing and following traces I think the pinouts make sense.
> > (Everything's conformal coated so it's a real bear to beep things out...)
> >
> > Any ideas?
>
> I have run across TI ICs from that era with odd/unknown series numbering,
> in particular the SN3900 and SN4500 DTL ICs.
> Notably:
> - by pinout they match up with standard DTL series ICs,
> - I have only found these in equipment from one manufacturer:
> calculators built by Canon.
>
> I received a solitary page of datasheet for some of them (by way of a
> Canon service center many years ago), but I have never seen them mentioned
> in TI databooks from the era, even in those sections where they list e.g.
> "other products from TI" and proceed to list little known series and part
> numbers.
>
> So an obvious guess is these were house numbering systems of standard
> parts done for the purchaser/equipment manufacturer but with TI's format
> scheme rather than a format specified by the manufacturer. Another guess
> would be standard parts tested and selected for purchaser-specified
> parameters, although that seems a little excessive for these cases.
>

Yeah, either of those options seems a likely possibility.  It definitely
seems like they were building this thing for bulletproof operation, so
maybe it really is the latter.


>
> The 54/7400 series originated with TI in 65, I'm not aware of them
> producing any other TTL series, other than perhaps second-sourcing some
> other manufacturer's.
> I guess that's another possibility - another manuf's TTL series, labeled
> differently.
>
> Odd that this Motorola CPU is filled with ICs manufactured by TI.
>

Yeah, the irony of this was not lost on me.  Other than the aforementioned
linear ICs in the core modules, every IC in this has a TI logo on it.


>
> It's conceivable, although it seems less probable, that they're DTL rather
> than TTL.
>
> On the whole, best guess would seem to be 7400-series inside.
>

Yeah, I'm guessing (hoping) 7400 as well, especially since there are actual
74xx-labeled ICs in here casually mixed with the 48xx and 63xx.

A thought occurred, that if I get desperate I could remove a few of the ICs
and attempt identification using the IC tester I have.  Not going to do
that unless I can't figure it out any other way.  The good news is there
aren't too many varieties.  I haven't done a full inventory but there's not
more than a dozen or so different types in here.


>
> --
>
> On another issue, did you trace the +/-15V lines to the core
> address/inhibit drivers?
> Could some of the remaining wires from the PS be other core supplies - 15V
> was a little low compared to most core systems I've seen.
>
>
I did manage to trace the +/-15V lines to the drivers on the core memory.
I don't believe any of the extra signals are other voltages -- three of
them go to the CPU board, one goes to the aforementioned mystery relay, one
goes to a tiny bit of logic on the mainboard (I suspect some manner of
LTC), and the last goes to a trace that just dead-ends and goes nowhere at
all.  The very little documentation I have on the CPU itself suggests that
the supply provided only +5 and +/-15.  There are two sets of power rails
for each; the first goes to the CPU, front panel, and two memory slots, the
second set goes to the other two memory slots.  I suspect that upgrading
past 8K of memory required a power supply upgrade.

- Josh

Re: Datasheet / Info for Motorola SC5330 IC?

[Josh Dersch via cctalk]

On Wed, Sep 30, 2020 at 7:48 PM Bob Rosenbloom via cctalk <
cctalk@classiccmp.org> wrote:

> On 9/30/2020 3:40 PM, Josh Dersch via cctalk wrote:
> > On Wed, Sep 30, 2020 at 2:41 PM Gavin Scott via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >> Josh wrote:
> >>> https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg
> >> Would these potentially be the sense amp / comparators for the core? I
> >> wonder if they were anything like:
> >>
> >> https://datasheetspdf.com/pdf-file/1092342/Motorola/MC1711L/1
> >>
> >> which might have a similar application and take +15 and -7 on L
> >> package pins 11 and 4 respectively with ground on pin 12.
> >>
> >> Being another Motorola design from what looks like a similar time
> >> period, I wonder if there could be a similarity in pinouts by some
> >> chance?
> >>
> > It's not an MC1711L based on that pinout.  (But I suspect as you do that
> > it's part of the sense amp for the core).  In particular Pin 1 of the IC
> is
> > connected to what I believe to be +15V.  (It's also hard to tell what
> pin 1
> > is, since there's no orientation marker on these... )  Ground is pin
> 10.  I
> > suspect -15V is pin 7.
> >
> > - Josh
> That pinout sounds like the Motorola MC1440 sense amp though the
> voltages are different.
>

Thanks, Bob!  That does seem to be the same pinout, at least for the
power/ground.  I think I've managed to convince myself of the correct
pinout for the power connector on this thing.  I have a suitable supply and
connector on their way...


- Josh


> Bob
>
> --
> Vintage computers and electronics
> www.dvq.com
> www.tekmuseum.com
> www.decmuseum.org
>
>