Re: DEC M9312 Configs for a 11/40

[Josh Dersch]

I can take some pictures of the M9312 I have running in my 11/40 tonight if
need be.  The manual at
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/unibus/M9312_TechRef.pdf
(page A-2) suggests that W8 should be IN.

Can you describe how your system is configured (i.e. what's on the bus,
what's in the CPU, etc?).

Have you double-checked that the interrupt vectors for your SLUs are
correctly configured?  The console (and BASIC, IIRC) does not use
interrupts for serial I/O and will work if the vector is misconfigured (I
discovered this the hard way in my 11/05) but other things will not and
will behave badly.

I'd also suggest using PDP11GUI to load in diagnostics directly, this
avoids needing to be able to boot XXDP...

- Josh


On Sat, Nov 26, 2016 at 9:58 AM, william degnan 
wrote:

> >
> >
> > 2) Yes or no - Should W8 be in for am 11 40/25/10/05 or is the /40
> > special?
> >
> >
> >
> TYPO - I mean "11 40/35/10/05" or is the /40 special?
>
> b
>

Re: DEC M9312 Configs for a 11/40

[Josh Dersch]

On 11/28/16 7:11 AM, william degnan wrote:





If you really want to make a bootable XXDP TU58 tape image, the
instructions given by AK6DN here:
http://www.vcfed.org/forum/showthread.php?42246-How-to-make-
a-bootable-XXDP-file-for-TU58-emulator



this is what I have been doing.


And what does the TU58 bootstrap do when you attempt to boot?  Do you 
see any activity over the second SLU talking to the emulator?





I use both the M9312 DL ROM and manually entering in the bootstrap without
the M9312 installed (replace with terminator card).   With the ROM method
the system repeats an attempt over and over.

system is looping between instructions 173022 -->173156 (error reset the
world), 173160 (retry)..back to 173022

When I first power on the values in the control status register (774400)
are good. 1-6 and 8-13 are cleared, bit 7 is set.
After I attempt to boot (DL at the @ prompt), you can see the light
pattern
repeat over and over, looping through 173022 -->173160.
I HALT the system and recheck the control status register. This time
15 - error (composite error (ERR))
10 - EO (operation incomplete (OPI))
7 - stays lit
function code F2 = 1, F1 =1, F0 =0. this code indicates "HFT" (Header Not
Found)

To me (and this is just me) the bootstrap is not waking up the RL11
controller, and can go no further.


According to the user's guide: http://bitsavers.trailing-edge
.com/pdf/dec/disc/rl01_rl02/EK-RL012-UG-004_RL01_RL02_
Disk_Subsystem_Users_Guide_Oct80.pdf

If the CSR bits are as you report, the drive got the Read command (that's
what F0-F2 indicate -- the last selected function, in this case "Read
Data").  Bit 15 indicates a composite error, and bit 10 indicates OPI, as
you note.  I don't see anything in there about HFT unless you left out some
bits.

If indeed bit 12 is set (indicating HFT) then the "Header Not Found"
indicates that the drive was unable to find the header for the sector on
the disk, which makes it look like the drive is trying to read but for
whatever reason isn't able to find the sector.  This could be a damaged
disk, misaligned heads, or any number of logic failures.

I would start with the RL02/RL11 diagnostics via either XXDP or PDP11GUI
and go from there.



this just bombs, does not run.  I agree though.  basically the computer
says "I can't reach the controller"
No it doesn't say that.  As indicated by the fact that you can see the 
controller's CSR register from the front panel and the console PROM 
monitor, and that the bootstrap is able to write to it during 
execution.  The controller is responding, and it's saying "sorry, I was 
unable to read anything."  If the controller wasn't responding, the CPU 
would trap on execution (a Bus Error Trap, to location 4).



I should add that the RL ROM (run DL0
from CONSOLE prompt) keeps trying over and over again, you can see it.  If
you run the bootstrap from the front panel it just dies.
Yes, this is expected.  If you look at the listing here: 
ftp://ftp.bluefeathertech.com/computing/hardware/legacy/DECboot/23-751A9/23-751A9.lst 
you can see that what happens on an error after a Read Data command is 
that the bootstrap does a RESET and jumps back to the beginning to 
retry, indefinitely.  (See line 91).  There is likely a problem with 
your drive, the controller, the disk, or the cabling, or some 
combination of these things.




What I can do next is make more note of the registers, see if I can get
more clues.
Yes, that might  be a good idea.  Single-stepping through the bootstrap 
(with the aforementioned listing at your side) might be revealing.  I 
assume you've run all the 11/40 CPU diagnostics and exercisers?




It just seems to me that there is a CPU or UNIBUS issue when I see
performance like this, again my hunch. It's not the controller.  If the
disk was bad, it'd at least try something, you'd see something.
You are seeing something, in the controller's CSR register.  What is it 
you're expecting to see?


- Josh




b

Re: DEC M9312 Configs for a 11/40

[Josh Dersch]

On 11/28/16 6:46 PM, william degnan wrote:


Recently (today) I noticed Address light 16 would come on when I examine
an address.  For example


All switches down, turn on machine  (set to 000 000)
RUN/PROC/BUS/CONSOLE lights come one, all other lights off
hit LOAD ADDR
address light 16 comes on, RUN/PROC/BUS/CONSOLE lights stay on.
If I hit START light 16 turns off.
If I try again, to load an address, the address I selected appears, but so
does light 16.

I believe I have seen the explanation for this symptom somewhere, but
reading the 11/40 CPU manual and handbook and I could not find the
explanation.  Does anyone know what this means?
I don't believe this has any specific diagnostic meaning.  It's possible 
that there is a stuck bit in the front panel logic.  It's also possible 
there is something wrong with the MMU, since (IIRC) the MMU is what 
drives address bits 16 and 17 from the CPU side.


If you load an address from the front panel, is it *actually* loading 
the address on the switches, or is it loading the address on the 
switches with bit 16 also on?  Try depositing a known word into a 
specific memory address, like 1000 using the console PROM, then try 
reading it back with the front panel.


- Josh



I have been booting directly into the console, lately the system has no
problem loading and running from the console.  Perhaps this huge missed
issue is the root of the problem I have been having get much else done.

Bill

Re: ISO: PDP-11/40 LTC and Stack Limit options

[Josh Dersch]

On 11/22/16 4:00 PM, Josh Dersch wrote:




On 11/22/16 9:27 AM, Noel Chiappa wrote:

 > From: Josh Dersch derschjo at gmail.com

 > see if the same is true for other bus grants -- I can run the 
system
 > with no grant continuity card at all in slot 9 and everything 
works.


Well, the BG4-BG7 grants definitely _are_ run through the SPC slot 9 
(see

below) - at least, on a stock system. It's _possible_ that the software
you're loading doesn't use interrupts. (I have this vague memory 
that, unlike
the -11/34, the /40 doesn't complain if there's a non-continuous 
grant line.)
Or perhaps someone wired them across on that slot, to avoid 
knuckle-mashing

trying to put a G727 down there.
Yes, I'd expect them to be run through the slot (though I expected the 
NPG, too :)).  And there does seem to be continuity between the BG 
pins on the CPU backplane and those on the DD11.


If I remove the grant continuity card from slot 9, I can still boot 
XXDP.  If I remove a grant continuity card from the DD11 (with NPG 
still intact), I can't  -- it hangs as I'd expect with a hole in the 
grant chain.


No one's done anything cute like hard-wiring the grants in and there's 
no evidence of any modifications.  All expected voltages are present 
on the backplane pins in the right places.  I put a little contact 
cleaner in the slot too, just in case.  I still can't get an SLU to 
function in that slot, though the CSR addresses seem to respond and 
the console/diagnostic PROM chugs along happily when I power the 
machine up (though nothing appears on the serial line).


Tonight I may try running the SLU on an extender board and verifying 
that all the proper voltages are actually making it to the board. The 
fact that the board appears to be responding but I'm getting nothing 
over the serial line makes me think that maybe the -15V isn't present 
for some reason...


Ad: mystery solved (?).  I had borrowed the SLU I was using in the 
11/40 from my 11/34.  This was an M7856 (DL11-W).  Thought I'd grab 
another SLU from my UNIBUS drawer and configure it up so I could put the 
7856 back in the 11/34, but all I had left were the older, more annoying 
to configure M7800s (DL11-D).  So I jumpered it up (max of 2400 baud 
with the crystal that's currently installed, blah) and installed it.  
Works fine in the DD11 backplane.


Moved it to slot 9 of the CPU backplane.  Still works.

So... maybe I just completely missed the memo on this, and maybe there's 
still something wrong with my backplane... is it possible that slot 9 of 
the 11/40's CPU backplane is wired *specifically* for an M7800?  I guess 
I need to spend some time tonight seeing what the differences are... but 
now I need to go attend to a cranky 2yo who just woke up from a nap...


- Josh

Re: ISO: PDP-11/40 LTC and Stack Limit options

[Josh Dersch]

On 11/22/16 9:27 AM, Noel Chiappa wrote:

 > From: Josh Dersch derschjo at gmail.com

 > see if the same is true for other bus grants -- I can run the system
 > with no grant continuity card at all in slot 9 and everything works.

Well, the BG4-BG7 grants definitely _are_ run through the SPC slot 9 (see
below) - at least, on a stock system. It's _possible_ that the software
you're loading doesn't use interrupts. (I have this vague memory that, unlike
the -11/34, the /40 doesn't complain if there's a non-continuous grant line.)
Or perhaps someone wired them across on that slot, to avoid knuckle-mashing
trying to put a G727 down there.
Yes, I'd expect them to be run through the slot (though I expected the 
NPG, too :)).  And there does seem to be continuity between the BG pins 
on the CPU backplane and those on the DD11.


If I remove the grant continuity card from slot 9, I can still boot 
XXDP.  If I remove a grant continuity card from the DD11 (with NPG still 
intact), I can't  -- it hangs as I'd expect with a hole in the grant chain.


No one's done anything cute like hard-wiring the grants in and there's 
no evidence of any modifications.  All expected voltages are present on 
the backplane pins in the right places.  I put a little contact cleaner 
in the slot too, just in case.  I still can't get an SLU to function in 
that slot, though the CSR addresses seem to respond and the 
console/diagnostic PROM chugs along happily when I power the machine up 
(though nothing appears on the serial line).


Tonight I may try running the SLU on an extender board and verifying 
that all the proper voltages are actually making it to the board. The 
fact that the board appears to be responding but I'm getting nothing 
over the serial line makes me think that maybe the -15V isn't present 
for some reason...


Anyway, the wire list in the drawings show all four lines (although they are
listed in two places, under "BGx" and "BUS BGx"). E.g. BG4 is shown on pg. 79
as going from D07E2 (Source - K4-6, pg. 63, top right) to D09S2 (which is the
correct BG4 'in' pin for SPC), and as BUS BG4 on pg. 84 as going from D09T2
(SPC BG4 'out' pin) to B09E2 (correct BG4 UNIBUS 'out' pin).

 > I now have the system booting XXDP

Yahh!!

 > I did find out why there was that wire missing on the backplane; the
 > KW11-L requires a wire (carrying one of the bus grant signals) be
 > removed from slot 3.

Right, BG6 is wired through that KW11-L slot because the clock needs
interrupts - the wire list shows that on pg. 79, where the BG6 entry is longer
than the other BGn entries, because of that. If I'm reading the notations
correctly, it shows the jumper installed by default - I guess it was removed
by hand on systems sold with a KW11-L?
The KW11-L manual suggests that this is the case, the installation 
instructions specifically call out removing that wire.  Apparently my 
40's backplane had been reconfigured in such a manner at some point.





There must also be some way to indicate that the jumper should be wired on
top at both ends (so the F03V2 to D09M2 wire wouldn't have to be removed to
pull the F03R2 to F03V2 jumper) - although maybe they just did _all_
multi-pin runs as alternating low on both ends, high on both ends, repeat to
make removal/replacement easier.

Speaking of notation, dunno if you knew this (I didn't), but the wire list
for the 11/40 includes etch also; you can tell etch entries from an 'H' in
the "Q" column and 'P' in the "Remark" column. Don't confuse them with the
'H' in the "A/P" column, which also also has some 'L' entries; not sure what
that is about, unless it tells whether the signal is asserted high or low.


That's useful information to have, thanks!

- Josh




Noel

Re: DEC M9312 Configs for a 11/40

[Josh Dersch]

On 11/27/16 4:28 PM, william degnan wrote:




Follow up -

I don't think I have issues with my M9312, thanks for your help.   There
are a number of candidate issues with my 11/40 which are causing my system
to not be able to initiate a bootstrap of the TU58 ROM using the M9312, or
bootstrap manually by using the front panel.

There is at least partial communication between the TU58 emulator (running
on Comm port 3) of my PC, the M7856's jumpers *I think* are correct to
serve as the serial card on the PDP 11/40 end.


So you've verified that the vectors on both your SLUs are correctly set?



I followed the settings found here:
http://www.pdp-11.nl/peripherls/comm/interface/dl11-w/dl11w-info.html



I have the LTC turned off.



(S59 off / S510 on)



There is always more testing I can do, but I suspect my issues are not
with
the serial card.  Taken holistically, I think there is a DMA UNIBUS issue
somewhere.  Just a hunch.


Can you elaborate on why you suspect this is the case?  Can you describe
your system in detail?



I have a CPU backplane populated as follows, I have checked the jumpers on
the CPU cards to verify that they're correct to the options installed
1: empty
2: M7253
3: M7232 (1-4) M7237(5)
4: M7231
5: M7233
6: M7235
7: M7234
8: M7236
9: empty with GC
CORE PLANES (2 slots 11-29 has only the first 16K populated.)
9/11: M981 (1-2)
11: M8293 (3-6) (start core plane)
12: M7259 (1-2)
13: G114
14: H217C
15: G235
16-18 empty (removed all core cards)
19/21: M9202 (1-2)
22-29 empty (removed all core cards)
29/31: M9202
DD11B:
31: 7800
32: gc
33: gc
34: 7856
34: M9202
DD11-C:
35: gc
36: NPR (jumper was removed at some point)
37: GC
38: 9312 / NPR

Thanks.  Where is the M7762 in this lineup?  You might try shortening 
the bus to eliminate extra variables (the second MM11 backplane, and the 
2nd DD11 backplane can be removed) but you're probably fine.  Based on 
the above, it looks like you've gone over all the grants and have the 
proper continuity cards and/or NPR jumpers in place.  I would also 
suggest cleaning the edge connectors on any that look dirty or oxidized, 
it can and does make a difference (in my experience).



If anyone knows of or would be willing to make an XXDP TAP image
compatible
with a 16K PDP 11 I can convert to download via PDPGUI.


PDP11GUI doesn't use TAP files.  You can use PDP11GUI to load individual
XXDP diagnostics into the PDP-11 without needing to boot XXDP at all.  Jörg
has provided a wonderful database of diagnostics here:
http://www.retrocmp.com/tools/pdp-11-diagnostic-database. Find the device
you need to test and grab the diagnostic binaries, listings, and
documentation and go to town.  (See section 5 of
http://www.retrocmp.com/how-tos/using-pdp-11-diagnostics/227
-pdp-11-diagnostics-running-them to see how that's done.)


I have done this, some success, but some inconclusive or hard to interpret
(for me).  I  thought I'd have better luck if I installed the entire XXDP
at my skill level anyway.  I am learning a lot but I did not work with this
equipment before.
If you really want to make a bootable XXDP TU58 tape image, the 
instructions given by AK6DN here:

http://www.vcfed.org/forum/showthread.php?42246-How-to-make-a-bootable-XXDP-file-for-TU58-emulator

have worked for me in the past.  You can use PUTR to throw more 
diagnostics on the tape if you need.


But you'll need to be able to actually do a TU58 boot, which it sounds 
like you've been having trouble with, so your mileage may vary.


Running the diagnostics stand-alone using PDP11GUI should work fine, and 
I've had good luck with it.  Just be sure to read the diagnostic 
instructions carefully so you know the starting addresses and the proper 
switch settings.  (Sometimes the instructions are in the listing, 
sometimes there's a separate document).






   Given I also have

issues initiating RL11 bootstrap (with known working equipment),


What issues are you having?  Does it hang?  Halt?  How are you
bootstrapping?  I assume you know the RL11 and the RL02 and the pack
involved are all known-working?



Yes the controller, cable, and disk were tested and working in another
system, recently.  I have more than one working cable and controller.  I
did not personally test the RL02s I have, but one was used a lot by the
previous owner, I have a 2nd that was also used by previous owner before I
took possession of them.

I use both the M9312 DL ROM and manually entering in the bootstrap without
the M9312 installed (replace with terminator card).   With the ROM method
the system repeats an attempt over and over.

system is looping between instructions 173022 -->173156 (error reset the
world), 173160 (retry)..back to 173022

When I first power on the values in the control status register (774400)
are good. 1-6 and 8-13 are cleared, bit 7 is set.
After I attempt to boot (DL at the @ prompt), you can see the light pattern
repeat over and over, looping through 173022 -->173160.
I HALT the system and recheck the 

Re: ISO: PDP-11/40 LTC and Stack Limit options

[Josh Dersch]

On 11/21/16 5:47 PM, Noel Chiappa wrote:


 > From: Josh Dersch

 > The 11/40 is mostly working ... but I've been unable to boot anything
 > (like XXDP, for example).

What are you trying to boot from?
I've tried an emulated TU58 and (most recently) a UNIBUS SCSI controller 
that I'm fortunate enough to have.





 > Slot 9 of the CPU backplane is supposed to be an SPC slot but it
 > doesn't seem to work

Missing/hard-wired BG/NPG jumpers on that slot, maybe?
The NPG jumper on slot 9 is not present, and it has no effect on the NPG 
chain if i jumper it or not (the bus seems happy otherwise...) There 
appears to be no continuity between CA1/CB1 of slot 9 and CA1/CB1 of the 
SPC/MUD slots in the rest of the system.  It's very puzzling.  I need to 
sit down with the wire list (and copious Excedrin) and probe things out.




If not, plug one of Guy's UA11's into that slot, and see what's up! :-)


 > I assumed I needed the KJ11-A because the KT11-D manual specifies
 > (bottom of page 2-1): "When the KT11-D Memory Management Option is
 > added to an existing PDP-11 system, the KJ11-A Stack Limit Register
 > Option must also be added." So I assumed the MMU required this option
 > be present...

Hmm, I didn't recall that; not sure I ever knew that! (Sorry!)

I spent a short time looking at the KT11-D and KJ11-A prints, trying to see
exactly what the KT11-D wanted, but I wasn't able (yet) to fully grok the
interaction.

>From the KJ11-A prints, you can probably work around not having a KJ11-A card
by strapping the relevant outputs high or low (as the case might be), i.e.
simulating a KJ11-A which is not reporting a problem. Like I said, V6 doesn't
use the SLR for anything, so it's it's not actually working (i.e. reporting
stack transgressions), no biggie.

If you're determined, I did scan in a KJ11's PCB, so it would probably be
possible to produce 'after-marked' ones - it's not a very complicated card.


Thanks for looking into it.  I'm not desperate for a KJ11 yet, but it's 
good to have resources should one need to be built...





 >> You will also need the KE11-E (M7238), as the Unix C compiler emits
 >> MUL, DIV etc, and even the bootstrap uses them. The KE11-F (M7239) is
 >> useless; the V6 Unix C compiler doesn't generate that type of PDP-11
 >> floating point.

 > Yeah, that might be harder to find, I'd forgotten about that
 > requirement. I suppose I could run Ultrix-11 instead (I have that on my
 > 11/34 at the moment) as it'll run sans floating point hardware,

We seem to be having a communication failure. You don't need floating point
to run V6 or V7 on an 11/40. In addition, the hardware floating point
hardware on the 11/40 (the FIS) is a variety that Unix doesn't support anyway
(in the sense of, the C compiler doesn't generate FIS instructions).

It's the Exteded Instruction Set (EIS) card (which supports MUL, DIV, ASHC,
etc) which is necessary. No way UNIX (of any flavour) will run without those
instuctions (and thus, that card). If you don't have an M7238, start
looking
Sorry, sorry -- long day and it's been awhile since I looked at the 
11/40 in depth (just dusted it off last night).  I thought I had picked 
up an EIS years ago shortly after I picked up the machine but either my 
memory is faulty or it's disappeared somewhere (the former is more 
likely at this point, I actually do have things somewhat organized 
here).  So that adds another level of fun.


Maybe at this point I should be happy to get RT-11 working :).





BTW, what is your mass storage device? RL's? If so, vanilla V6 doesn't support
RL's, but I do have a V6 RL driver, I can either build you a system that will
run on an RL, or (if you bring up V6 under an emulator, so you can build
systems, etc) provide it so you can add it. You'll also need an RL bootstrap
(again, those are available, but not in vanilla V6).

Also, how are you getting the bits onto the mass storage? V6 can only be
'cold installed' onto a blank machine from a TM11 or TM02 tape drive. Failing
that, you have to put a V6 filesystem onto a disk on some other machine. Do
you have the ability to write packs on another machine/OS, and the ability to
get a Unix file system onto that system? Failing that, I'm in the process of
getting VTServer working to transfer V6 over a serial line to a blank machine
(my situation) - I got distracted before I got 100% finished, but I have it
all scoped out, and can get it done in a couple of hours from where I am now.


I have an RK11 and an RK05 (with the option of a 2nd RK05 if I ever get 
some mounting rails for it.)  I know the RK05s are tight storage-wise. I 
also have an RL02 but I need to repair an RL11 first.  (And there's 
always the SCSI controller, should I get up the nerve to backport an 
MSCP driver...) I should be able to wrangle bits onto media either using 
what I 

TI 990/189 debugging

[Josh Dersch]

Hi all --

Got myself a TI-990/189 single-board computer based around the TMS9980 
microprocessor (actually, a variant of it, the MP9529, which apparently 
differs only in that it has a lower maximum clock and only requires Vdd 
of 9.3V or so...)


It was advertised as "it looks like it's working, but who knows" and so 
of course it arrived and it's dead.  It powers up and nothing appears on 
the display,  and the CR1-CR4 and SHIFT LEDs are illuminated.  No 
response whatsoever.


I've spent some time yesterday and today probing the thing and I think 
the CPU is dead, but I wanted to run it past the braintrust here in case 
anyone has any experience with the 9980...


Here's what I see:

Voltages are all nominal on the +12, +5 and -5 supply; +5 and -5 are 
present at the CPU, as is 9.3V for the VDD.


At the CPU:

- CKIN is clocking at the right rate, the phi3 clock generated by the 
CPU is also correct.


- IAQ is not pulsing, so the CPU is not fetching instructions

- The Address and Data lines are all zeros with no activity whatsoever

- HOLDA is low, -HOLD is high (so the CPU is not being held)

- READY is high

- MEMEN is low (so no memory accesses are taking place)

- INT0 through INT2 is 010 (which indicates that a LOAD interrupt is 
active, more on this later)


I have verified that the POWERGOOD signal is going high after about a 
second after power-on, as expected (this causes things on the board to 
RESET appropriately).  This in turn causes the -LOAD signal from the 
Power Up/Reset circuit to go low, which causes INT 1 to go high.  (This 
is later supposed to be reset, once the CPU's IAQ line clocks after the 
first instruction is executed, but since that's dead, well, nothing 
happens.)


Based on this, I believe the CPU to be faulty.  Anyone have any thoughts 
on this?


Given the VDD difference (12V vs 9.3V), I don't think a standard TMS9980 
will work; the MP9529 seems to be difficult to source, but it shouldn't 
be hard to get 12V to the CPU...


Thanks,

Josh

Re: Datamation, May 1972

[Josh Dersch]

On Thu, Nov 17, 2016 at 12:44 PM, Kyle Owen  wrote:

> On Thu, Nov 17, 2016 at 10:10 AM, Paul Koning 
> wrote:
>
> >
> > Interesting.  From around 1975 or so, and worth learning about is the
> > music synthesizer developed on the PLATO system at the University of
> > Illinois by Sherwin Gooch.  The hardware is described in great detail
> > (including full schematics) in US Patent 4,206,675.  The software
> includes
> > a music code compiler, using a code somewhat like the one you referenced
> > but different in details.  I don't know if one borred from the other or
> if
> > they are independent inventions.  (Sherwin might remember.)
> >
> > A few years later PLATO added a 16 channel waveform synthesis device,
> > controlled by the microprocessor in the terminals.  It had a similar
> music
> > code, plus support for a piano keyboard (with key velocity sensing) for
> > music input with real time display of the score, as well as score
> > printing.  Not long after, Lippold Haken created a keyboard that's
> > continuous rather than discrete (think of a keyboard like the fingerboard
> > of a violin); a successor of that is still sold today.
> >
>
> I'd be very interested in any sound samples, if anyone has any...I guess
> that's perhaps unlikely. And on that note (heh), are there any other
> computer music albums out there? I know of the First Philadelphia Computer
> Music Festival, the two Unplayed by Human Hands, and it looks like the
> University of Melbourne had an electronic music album too. There's a 45
> entitled Computer Composites that featured several IBM systems,
>
> I'm finding it rather difficult to find LPs that are assuredly produced by
> a digital computer versus by other electronic means, like early
> synthesizers, etc.
>

I have an LP, "Electronic Music from the University of Illinois" (1967 or
so):
https://www.discogs.com/Various-Electronic-Music-From-The-University-Of-Illinois/release/349054.
If I recall, they used the U of I's ILLIAC IV in the recording.

It's somewhat interesting but the electronic parts of it are sometimes hard
to discern :). Looks like someone's digitized it here:
https://www.youtube.com/watch?v=0ueVm8WvRHI.

I digitized an 45 of music generated by an Orchestra-80 (TRS-80 4-channel
synth), it's called "Classical Mosquito!" -- you can grab it from here:
http://yahozna.dyndns.org/scratch/mosquito/

As an aside, I've been (slowly) working on emulating Ted Kaehler's organ
keyboard / FM synth for the Xerox Alto (c. 1974) in ContrAlto.  I have just
enough technical information and code listings to make it possible, but
there's just enough information missing to make it difficult...

- Josh



>
> Thanks, Al, for the scan upload! I've enjoyed reading that.
>
> Kyle
>

Re: Some scrapper in NC has an old machine Labled TRIAD he is scrapping

[Josh Dersch]

Looks like a rebadged Interdata 7/32 (or similar) to me.  Someone should 
try to rescue that; they're very rare...



- Josh


On 11/19/16 8:35 PM, TeoZ wrote:

http://www.scrapmetalforum.com/general-electronics-recycling/30872-old-computer-peripherals-main-frame-etc-should-i.html



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 7:20 PM, Josh Dersch <dersc...@gmail.com> wrote:

> On 11/9/16 6:18 PM, Paul Koning wrote:
>
> On Nov 9, 2016, at 5:57 PM, Josh Dersch <dersc...@gmail.com> wrote:
>>>
>>> ...
>>> A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
>>> recollection (this is what I get for not taking notes at the end of
>>> yesterday, and yesterday seems so far away now...).  The first test (a
>>> forward WALL, followed by an RALL of a single block) fails with the
>>> following spew (for example):
>>>
>>> BLKRQ 000310 DATA ERR  WORD 00054.  S/B 176376  WAS 104106
>>>
>>> Based on a reading of the fiche listing (which is a slightly newer
>>> revision
>>> of the binary I have) I believe S/B is the expected data and "WAS" is the
>>> read-back data for a given word.  Since one appears to be the obverse
>>> complement of the other, it looks like the obverse complement logic is
>>> running when it shouldn't be...
>>>
>> Yes, those two patterns are indeed obverse complement.  Word 0054?
>> That's odd, if it's doing this wrong for a word in the middle of the
>> buffer.  Can you have it halt on fail so you can examine the buffer?
>>
>> paul
>>
>>
>>
>> It's actually word 4 (transcription error on my half) and it reports
> errors for all words in the block (though the reported word number doesn't
> actually correspond in any meaningful way to the word on tape, per the
> documentation); i just singled that one out for an example.  They all show
> the read data being the obverse complement of the expected data.  I'll be
> doing some serious debugging tomorrow...
>
> - Josh
>

So a small update:

I spent some time probing various signals and I couldn't find anything
obviously wrong; while the failing diagnostic was running, the obverse
complement logic in the hardware was behaving as I'd expect (i.e. it wasn't
being used, since an RALL was in effect).  I went so far as to write my own
little test program that does basically what the ZTCD diagnostic Test 0
does -- a WDATA (forward) followed by a RALL (forward) and a comparison of
the data, and everything came back clean.

But I gained a better understanding of how the TC11 hardware works and how
it's programmed, so that's always a good thing.

And that knowledge helped me when I went back to the RT-11 formatter to see
if I could work out what was going wrong there.  As you recall, the
formatter was failing after writing the T tracks with a Data Miss (DATM)
error.  Data Miss in this case would indicate the software not responding
in time to the READY signal during a RALL command, which is interesting --
this would seem to indicate more of a software problem than a hardware one.

I noticed the following commented-out line at the beginning of the program:

START:
;   RESET   ;CLEAR THE WORLD
;   MOV #P7,PS  ;LOCKOUT P1 BY RAISING CPU PRIORITY <<

Uncommenting the MOV #P7,PS line allows the formatter to run properly.
It appears that interrupts (I'd guess the LTC interrupt) were taking
enough time away from the program to cause it to miss data; I'm
guessing it's because I'm running the FB monitor rather than the SJ
monitor, but I'm not familiar enough with RT-11 yet to know exactly
where to place the blame.

At any rate, at this point I'm able to format a tape, initialize it in
RT-11, and copy/verify files onto it without any issues.  The failing
diagnostics are still puzzling, but I'm almost ready to throw in the
towel on them :).

- Josh

ContrAlto V1.1 Released

[Josh Dersch]

Hi all --

Just wanted to let you guys know that a new version of the Xerox Alto emulator 
I've been working on at the LCM+L has been released; V1.1 of ContrAlto can be 
downloaded from: http://www.livingcomputers.org/Join/Online-Systems.aspx.  At 
this point, the vast majority of software appears to be working properly, if 
you do run into any issues please let me know!

ContrAlto is open source, so if you want to hack on it the source is available 
on our GitHub site at https://github.com/livingcomputermuseum/ContrAlto.

Thanks!
- Josh

RE: ContrAlto V1.1 Released

[Josh Dersch]

OK, one more time with feeling, because apparently when I pasted that link it 
added a bunch of garbage (thanks, Outlook Web Access!).

If you want to get ContrAlto, the actual, real, working link is:

http://www.livingcomputers.org/Join/Online-Systems/ContraltoSetup.aspx

Sorry for the confusion and/or stupidity on my part...

- Josh

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Josh
> Dersch
> Sent: Friday, October 28, 2016 9:30 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@classiccmp.org>
> Subject: Re: ContrAlto V1.1 Released
> 
> On 10/28/16 5:56 AM, william degnan wrote:
> 
> > On Thu, Oct 27, 2016 at 4:22 PM, Josh Dersch
> > <jo...@livingcomputers.org>
> > wrote:
> >
> >> Hi all --
> >>
> >> Just wanted to let you guys know that a new version of the Xerox Alto
> >> emulator I've been working on at the LCM+L has been released; V1.1 of
> >> ContrAlto can be downloaded from: http://www.livingcomputers.
> >> org/Join/Online-Systems.aspx.  At this point, the vast majority of
> >> software appears to be working properly, if you do run into any
> >> issues please let me know!
> >>
> >> ContrAlto is open source, so if you want to hack on it the source is
> >> available on our GitHub site at https://github.com/
> >> livingcomputermuseum/ContrAlto.
> >>
> >> Thanks!
> >> - Josh
> >>
> >>
> >>
> >>
> > Having trouble reaching a link following through to download from
> > http://prevlcm2.corp.vnw.com/Join/Online-Systems/ContraltoSetup.aspx
> >
> Yep.  Our new website is going through some teething problems. Until
> they're resolved, use:
> 
> http://www.livingcomputers.org/Join/Online-Systems/ContraltoSetup.aspx
> <https://mail.vulcan.com/owa/redir.aspx?C=zDjrHPRZbJW_iYBHBE6hxlLP0M
> Va7eQPnMcovYMFBZkfQxyQT__TCA..=http%3a%2f%2fwww.livingcom
> puters.org%2fJoin%2fOnline-Systems%2fContraltoSetup.aspx>
> 
> To download the emulator.
> 
> Thanks,
> Josh

Re: Gaming on old systems (was Re: Twiggys [was: Re: ka... ching!])

[Josh Dersch]

On 10/11/16 9:06 AM, Charles Anthony wrote:


On Tue, Oct 11, 2016 at 8:44 AM, william degnan 
wrote:



DOS PC: Doom



Last comment from me...

I played SGI Doom the other day for the first time.  There are always new
discoveries, I did not even know this port existed.


As I understand it, the SGIs were the development platform for DOOM, and
the PC version is the 'port'.

That's incorrect -- DOOM was developed on NeXT hardware.

- Josh


-- Charles

Re: Gould 32/77 (was: NWA auctions)

[Josh Dersch]

On 10/13/16 9:14 AM, Al Kossow wrote:



On 10/13/16 9:01 AM, Rick Bensene wrote:


These are neat machines, and I hope that they end up in the hands of
someone that can care for them rather than ending up scrap.


hope ht was one of us :-)






I ended up with the TI-980.  The 11/45's got out of range for me...

9 minutes left on the other Gould 32/77; hope someone here ends up with 
it...


- Josh

Re: NWA auctions

[Josh Dersch]

On 10/13/16 1:37 PM, Noel Chiappa wrote:


 > From: Jim Stephens

 > The two bay 11/45 went for twice the bid, since it was listed as 2 pcs
 > @ 1500 each

Yeah, I couldn't quite work that out - did it mean there were two mostly
identical ones, and they only had pictures of one, or did it mean 'two racks'?

Noel



It means (as far as I can tell) "two items" where the items in this case 
are the two racks.  You're buying the lot, but bidding on the cost of a 
single item. The TI 980B I got 
(https://grafeauction.proxibid.com/asp/LotDetail.asp?lid=32464722) was 
sold as three items (the rack, the printer on the small rack, and some 
weird readout on a rolling pedstal).  No, it doesn't make an incredible 
amount of sense for some of this...


- Josh

Re: Gould 32/77 (was: NWA auctions)

[Josh Dersch]

On 10/13/16 8:34 PM, Bob Rosenbloom wrote:


On 10/13/2016 9:01 AM, Rick Bensene wrote:

I'm curious what the Systems 32/77 is..
Wasn't Gould SEL?  maybe an SEL system?


The 32/77-series was a 32-bit machine implemented in ECL, based on
earlier SEL designs, but is definitely Gould in design/manufacture.

Some of the machines in the series had a very powerful (for the time)
floating point unit (known as the IPU) that operated in tandem with the
main CPU that vastly increased the number-crunching power available

The machines were mainly intended for real-time control applications (as
used in the flight sim applications in the auction)

The machine ran a real-time executive called MPX-32.

More information: http://www.encore-support.com/htmls/32_77.htm

Years ago, I had some experience with these machines.  They were quite
powerful for their time, and were also workhorses that just ran and ran.
Very robust design.

These are neat machines, and I hope that they end up in the hands of
someone that can care for them rather than ending up scrap.

--
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com




Well... with a momentary lapse of reason, I bought the Gould / SEL 
system. It won't go to scrap.
No idea how I'm going to get it, and what I'm going to do with it, but 
after reading about it last night,

I thought it might be fun to play with. We'll see...


Very nice!  Glad it's not going to scrappers, I was seriously debating 
bidding on one of the two systems but I just don't have the room.  I'd 
love to see pictures of this thing once you manage to get it back to 
your place.


- Josh




Bob

Re: NWA auctions

[Josh Dersch]

On 10/13/16 12:11 AM, Pontus Pihlgren wrote:


On Wed, Oct 12, 2016 at 09:13:19PM -0700, Al Kossow wrote:

https://grafeauction.proxibid.com/asp/catalog.asp?aid=117590=288#288

someone needs to grab those 11/45's!


What are those modern looking peripherals? Looks like storage, it might
be the real find here.

Also don't miss out on the VT330 (color graphics terminal!) and
Documation card reader.

I'm curious what the Systems 32/77 is..

/P



The WBC 3000s in the 11/45 rack are RK05 emulators, from what I've been 
able to determine.


The Systems 32/77 is a Gould/SEL machine.  32-bit, ECL.  I don't know 
too much about it, but it's cool looking.  Wish I had the space...


- Josh

Re: NWA auctions

[Josh Dersch]

On 10/12/16 9:13 PM, Al Kossow wrote:

https://grafeauction.proxibid.com/asp/catalog.asp?aid=117590=288#288

someone needs to grab those 11/45's!




Thanks for the tip!  Against my better judgement I put in a bid on the 
one without the trim on the faceplate...


- Josh

Re: NWA auctions

[Josh Dersch]

On 10/12/16 10:08 PM, jim stephens wrote:




On 10/12/2016 9:37 PM, Josh Dersch wrote:


On 10/12/16 9:13 PM, Al Kossow wrote:

https://grafeauction.proxibid.com/asp/catalog.asp?aid=117590=288#288

someone needs to grab those 11/45's!




Thanks for the tip!  Against my better judgement I put in a bid on 
the one without the trim on the faceplate...


- Josh


Will you help get one of the 747 full motion boxes back to my house?  
they have several of those, plus several DC-9 simulators. :-)


Anyone interested in Gould or in Evans & Sutherland should look thru 
all the listings.  There is one tall cabinet that appears full of E 
equipment.


thanks
Jim



Sure thing :)

Any idea what this might be?  Looks interesting, but not a lot of 
information to go by apart from the "Display Systems Incorporated" badges...


https://grafeauction.proxibid.com/aspr/Portable-simulator-display-screens/32464587/LotDetail.asp?lid=32464587

- Josh

Re: MFM floppy and HD emulator DREM

[Josh Dersch]

On Mon, Oct 17, 2016 at 10:21 AM, Guy Sotomayor Jr 
wrote:

>
> > On Oct 17, 2016, at 9:58 AM, j...@cimmeri.com wrote:
> >
> >
> >
> > On 10/17/2016 11:18 AM, Peter Cetinski wrote:
> >>> On Oct 17, 2016, at 11:58 AM, emanuel stiebler  wrote:
> >>>
> >>> Hi all,
> >>> anybody has any experience with that:
> >>>
> >>> http://www.drem.info/
> >>>
> >>> ?
> >> Yes, I'm currently in the process of getting the DREM working with a
> Tandy 6000 and Xenix.  ...
> >
> > About $250?   Wish it were half that.  Seems like they could sell more
> than twice as many at half the price, and more than 4 times as many at
> 1/4th the price.
>
> Really?  Come on guys, this stuff costs $$’s to produce and they may
> actually want to make some profit.  If you’re doing small volume stuff
> (10’s-100’s vs 100,000’s - 1,000,000’s) it’s going to be a bit pricey.
> Frankly, to get the price to drop to half ($125), you’d probably have to
> get 10x-100x quantity increase.  I know because I face the same thing when
> trying to produce my boards.  Assembly will typically double the cost of
> the board + components.
>
> I’ll likely be getting at least 3 of them (1 for the IBM 3174 and 2 for my
> Symbolics 3640 and possible another 2 for my other Symbolics 3640).
>

Don't, at least not for the Symbolics gear.  The DREM only works with hard
drive controllers it knows about, and the Symbolics ain't one of them.  I
chatted with the developers about what it would take to support them and
they see it as being possible, but couldn't commit to it without having
hardware on hand to test with.  And given how hard it is to get a Symbolics
machine to even format a disk once you have a working machine, it's not
likely to happen anytime soon.

- Josh


>
> TTFN - Guy
>
>

TI 980 software?

[Josh Dersch]

Hi all --

The TI 980B I got from that NWA auction from a month or so ago finally 
made its way back to my house, and the CPU looks to be in decent shape.  
I'll probably start working on restoring it after the new year.  
Bitsavers has ample documentation, but I haven't found much software at 
all -- I don't suppose anyone out there's got any tucked away somewhere?


I've found this: http://www.cozx.com/dpitts/ti980.html which provides a 
nice cross assembler/linker and simulator so I guess I can write my own :).



I was hoping there'd be a bit more to the system than the CPU, but the 
rack it came in was effectively empty apart from the CPU, a gigantic 
power supply and an empty backplane and card-cage. There was a stack of 
documentation included, so now I know that this TI was originally part 
of an Evans and Sutherland "NOVOVIEW 2500" -- a "Night Only View" flight 
simulator that used a set of point-plotting X/Y beam-penetration 
displays (red/orange/amber/yellow/green colors) to simulate a runway at 
night.  (These were the DSI displays that were auctioned off as a 
separate lot, wish I'd known what they were at the time...) Pretty 
interesting, a shame all of the cool hardware was stripped out at some 
point.  Based on the printout stuck in the Omni 800 that came with it, 
this was in use through at least 2000.


Thanks,

- Josh

Re: IBM XT 5160 Keyboard issues

[Josh Dersch]

On 12/17/16 9:14 PM, Devin wrote:

I was happy to find a IBM XT for a good price at the scrapyard today 
in very nice condition. It is missing the hard drive, but i have 
plenty of those, the controller was still inside.


I had a little issue getting video working at first, i do not have a 9 
pin cga monitor laying around, thankfully i found a 16 bit isa card 
that also works in an 8 bit slot.


The machine starts up and runs its memory test, however it gives a 301 
error. System halts and says press f1 to continue, but no luck, 
keyboard is unresponsive. I have tried about 10 different keyboards on 
the machine, including some model M keyboards with a ps2 adapter with 
no luck.


Model M keyboards are AT-style keyboards, they won't work with an XT 
(different protocol).  You will need to find a PC/XT compatible keyboard 
to use.


- Josh




A quick search does turn up that 301 is a keyboard related error, but 
i am not sure what exactly the issue is.


Am i doing something stupid here or am i looking at the possibility of 
something being wrong with the machine?


--Devin

Re: What's the rarest or most unusual computer-related item do you own?

[Josh Dersch]

On 1/10/17 3:29 PM, Chuck Guzis wrote:


On 01/10/2017 02:09 PM, Andy Cloud wrote:

Hi Everyone!

I thought this would be an interesting question to ask around -
What's the rarest or most unusual computer-related item do you own?

For me, personally, I have a Altair 8800!

Looking forward to hearing your answers

That's a tough one.  A 1401 core plane?   Some CDC 6000 "cordwood"
modules?  Two Durango F85s, complete with 14" Shugart hard drive?

Got a couple of boards that I don't even know the provenance of.

PSU diodes and heatsink from a STAR 1B?

Lotsa junk.

--Chuck



.



For me:
 - AMT DAP 610 (64x64 array processor, probably only a few hundred made)
 - Imlac PDS-1D (early graphical terminal/computer, 1971)
 - PERQ-1A (early graphical workstation, bitslice CPU, goodness all around)
 - RGS 008 micro (8008 kit from 1974-1975 with switches and blinkenlights)

- Josh

Re: Winchester-style coax connectors?

[Josh Dersch]

On 12/2/16 8:29 AM, Jon Elson wrote:



On 12/01/2016 01:27 PM, Josh Dersch wrote:

  but what I failed to notice is that three of
the "pins" (for the X, Y and Blank signals) are actually tiny coaxial
connectors that fit within the Winchester housing (i.e. they're the same
diameter as a Winchester pin).


These pins MIGHT be compatible with AMP pins for the "M" series of 
connectors.  If so, I have some of these pins at work that we will 
likely never use.  If you can send a photo of the end you have I can 
see if it looks like it might work.


Jon



Here's a pic of a real Imlac video cable (not mine):

http://yahozna.dyndns.org/scratch/imlac/cable1.jpg

Pins P, J and R are the coaxial pins.

And here's a pic of the male side:

http://yahozna.dyndns.org/scratch/imlac/cable2.jpg

If you do have any that look like they will work, let me know.  I think 
I may have tracked down the part (thanks to those here and a fellow who 
responded off-list, see page 15 of 
https://3o9g5a3i56xc3au70w1rfrdv-wpengine.netdna-ssl.com/wp-content/uploads/2016/09/C009RevD_StdDenRec.pdf).



Thanks,
Josh

Re: Winchester-style coax connectors?

[Josh Dersch]

On Thu, Dec 1, 2016 at 11:47 AM, Paul Koning <paulkon...@comcast.net> wrote:

>
> > On Dec 1, 2016, at 2:27 PM, Josh Dersch <dersc...@gmail.com> wrote:
> >
> > ...
> > The Imlac uses a Winchester connector (14 position) for the display and
> > while they're not as common these days the parts can still be found so I
> > thought I was in the clear, but what I failed to notice is that three of
> > the "pins" (for the X, Y and Blank signals) are actually tiny coaxial
> > connectors that fit within the Winchester housing (i.e. they're the same
> > diameter as a Winchester pin).
>
> What is a "Winchester connector"?  Do you mean a D-sub connector, i.e.,
> with a trapezoidal shell such as you find on terminal or VGA connectors?
> Those come in a number of widths, with names like DE (for the VGA size), or
> DB (the 25 pin classic RS-232), and so forth.  Often, incorrectly, all are
> called DB.
>
> Those shells have a variety of choices for pins.  They may be two rows of
> pins (e.g., DB-25), or 3 rows (e.g., DE-15).  You may also find ones that
> have just miniature coax inserts, or a mix of coax and plain pins.  The
> coax inserts are generally larger, such that it takes up much of the height
> of the connector.  I haven't seen coax pins that are the same diameter as
> plain signal pins, that's rather hard to imagine especially for something
> as old as an Imlac.  Examples of mixed pin D-sub connectors are the Sun
> video monitor connectors, with RGB on coax.
>
> paul
>
>
>

Like one of these bad-boys, only with 14 connectors rather than 34:

http://cables24.com/en/others/cable-v-35/1470-V-35-m34-Winchester-34pin-male-connector

Sorry for not being more specific.  The coax connectors in a 13W3 connector
(for example) are much larger than what I need.

- Josh

Winchester-style coax connectors?

[Josh Dersch]

Hey all --

Due to a small miracle I now have 8KW of perfectly functioning core in my
long-ill Imlac PDS-1D.  The last hurdle is devising a replacement for the
missing display (an X/Y vector display).  For the time being I'm going to
attempt to use an oscilloscope, but first I need to build a cable.

The Imlac uses a Winchester connector (14 position) for the display and
while they're not as common these days the parts can still be found so I
thought I was in the clear, but what I failed to notice is that three of
the "pins" (for the X, Y and Blank signals) are actually tiny coaxial
connectors that fit within the Winchester housing (i.e. they're the same
diameter as a Winchester pin).

I haven't been able to track these connectors down anywhere.  Anyone have
any ideas?

Failing that, I can always just tap into the backplane to pick up these
signals and ignore the connector on the bulkhead, but it would be nice to
be able to use the original connector...

- Josh

Fix for 4.3BSD-Quasijarus bootstrap on CMD SCSI controllers

[Josh Dersch]

Hi all --

Thought I'd share this fix with you all just in case someone in the 
future might make use of it.


Long story short:  Got myself a CMD 710/M UNIBUS SCSI controller with 
the intent to use it in my VAX-11/750, running 4.3BSD-Quasijarus.  
Unfortunately it won't boot (it hangs shortly after "loading boot" is 
printed to the console).  VMS boots, NetBSD > 1.6 or so boots, Ultrix 
boots, but no luck with 4.3BSD.


I spent some time adding some debug spew to the bootstrap (on SIMH) and 
testing (on the 750), and the hang is inside udcmd() in 
sys/vaxstand/uda.c.  I then stumbled on this usenet post:


https://groups.google.com/forum/#!msg/alt.sys.pdp11/61LZNTo9Dgg/Q6dI9om_LIEJ

Which indicates a similar problem with a Viking controller on a 
different 4.3BSD variant.  The code in Quasijarus is a bit different, 
but the cause is the same.


The fix is:

Change line 155 of sys/vaxstand/uda.c from:

if(u->uda_ca.ca_rspint ==0)

to:

if(u->uda_ca.ca_rspdc & MSCP_OWN)

Rebuild, and re-run disklabel to replace the bootstrap.

Hope that helps someone else someday...

- Josh

Re: was: National Semi... is Apple ][ collectability (if any)

[Josh Dersch]

On 1/3/17 12:09 AM, jim stephens wrote:




On 1/2/2017 11:26 PM, Brad H wrote:
I brought the RFI thing up with him.  No response.  There is a legit 
Rev 1 there too asking $3500.  I don't find Apple IIs below Rev 0 
that interesting anymore, personally.  I think even the legit guy 
would struggle to get much above $1500.
The vintagecomputer museum guy on epay is selling mounted and framed 
motherboards now for $1500 (might not work noted).


I guess someone would care about low ref Apple 2's but I'm not sure 
why there would be any interest.  I've got one I bought with the 
original packing box, which I have picked and moved twice, which is 
rare for my collecting, but I don't know what makes any Apple 2 like 
that collectible.  As in why are they collectible with low serials / 
part numbers.


Apple/Jobs fetishists.  They'll never own an Apple I, so they want the 
next best thing -- an Apple II with a really low serial number. S/N 25 
recently sold for just under $15k.  The early revs are not really all 
that different than the later ones (Rev 0. has color fringing on text, 
Rev 1. removed the (tiny) prototyping area, after that the revisional 
differences get even more mundane).  If you want an Apple II to play 
with (as opposed to worshiping), a II+ will do the job, is nearly 
identical to a straight-II, and no one seems to care too much about them 
so they're still cheap.


It seems (from watching eBay over the past few years) that S/N's less 
than about 9K tend to go for more ($1000+), and the closer you get to #1 
the crazier it gets, obviously...


- Josh




is there any documentation as to when they were made with those 
numbers that would make them significant?  The numbers made as Raymond 
said would make most of us with Apple 2's millionaires I'd think 
unless they have some other significance.


just curious.
thanks
Jim

Re: Fix for 4.3BSD-Quasijarus bootstrap on CMD SCSI controllers

[Josh Dersch]

On 1/3/17 12:50 PM, David Brownlee wrote:


On 3 January 2017 at 20:11, David Brownlee <a...@absd.org> wrote:

On 3 January 2017 at 15:50, Noel Chiappa <j...@mercury.lcs.mit.edu> wrote:

 > From: Josh Dersch

 > Thought I'd share this fix with you all just in case someone in the
 > future might make use of it.

To help disseminate it, I uploaded the fix to the Computer History wiki:

   http://gunkies.org/wiki/CDU-710/M_disk_controller


 > From: Lars Brinkhoff

 > There's no central repository for fixes like these?

Well, the CH wiki would be a good place, but creating new accounts on it is
proving to be difficult.

I'm trying to get ahold of one of the two bureacrats, to make me an admin
(I've been one on Wikipedia since the Devonian), so I can create accounts for
people, but so far no luck.

 Noel

Would it make sense for someone to import it to github?

If nothing else it should be be easy enough to start with 0, then
update to 0a 0b and then 0c. so we have what history is available.

(checks github)

Aha - I see that johnwfinigan has already put up a 0c, though it
doesn't seem to have the 0, 0a & 0b history
https://github.com/johnwfinigan/4.3BSD-quasijarus0c/commits/master

Actually I might just do the 0..0c history into a github entry myself,
then anyone else can just {v,}fork and take it from there as desired :-p

No sooner said than done :)

In case it proves of interest to anyone. Happy for it to be forked
(obviously!) or to have patches or pull requests punted back to me

https://github.com/abs0/4.3BSD-Quasijarus

David



Very cool, thanks for setting that up!  I have one other fix for the 
UDA50 driver (that allows Emulex SCSI controllers to work properly) that 
I'll combine with my CMD fix and I'll send you a patch when I have it 
ready...


- Josh

Re: TI 990/189 debugging

[Josh Dersch]

Just to bring some closure to this old thread, I finally picked up a
working TMS9980 cpu chip (after getting one faulty one off of eBay -- it
was even more dead than the one it was replacing).  And it appears to work
properly in the 990/189 board, with the 9.3V supplied on the CPU socket.

Thanks,
Josh

On Thu, Nov 17, 2016 at 3:05 AM, Eric Smith  wrote:

> 9.3V might actually work fine for a TMS9980, even though it's below spec.
> It's not going to damage the part, so it may be worth a try before
> modifying the board for 12V to the CPU socket.
>
> In NMOS digital parts that predate depletion loads, Vdd needs to be
> significantly higher than the most positive logic level in order to bias
> the enhancement nFET used for the loads (pull-ups).  The Vdd voltage
> doesn't have to have a precise value, but it needs to be somewhat more than
> the FET gate threshold above the most positive logic level, and below the
> breakdown voltage.  The higher the Vdd voltage (below breakdown), the
> faster the pullup will operate, so running below spec will reduce the
> maximum speed at which the part will operate. This is also dependent on
> temperature.  The part is spec'd for operation over a fairly wide
> temperature range (even if only "commercial" rated). Since the logic high
> level is no more than 5.0V, and generally somewhat less, a Vdd of 9.3V is
> probably more than adequate at room temperature, but may fail at
> temperature extremes.
>
> The MP9529 is a "selected" TMS9980.  In most contexts, a "selected" IC is
> one that has been tested and found to meet specifications more stringent
> than the normal specifications.  However, in this case I think the MP9529
> might actually be "selected" in the sense of being tested to *lower*
> specifications than a standard TMS9980. It's unclear why they would want to
> use the lower Vdd, except possibly to reduce power consumption.
>
> With the introduction of depletion loads in later NMOS ICs, generally
> starting around 1976, and becoming ubiquitous by 1980, the requirement for
> a supply above +5V was eliminated. Similarly, by adding an on-chip
> substrate bias generator, the need for an externally supplied substrate
> bias voltage (Vbb, typically -5V) was removed.
>

Re: National Semiconductor IMP mini

[Josh Dersch]

On 1/2/17 7:22 PM, jim stephens wrote:
This system looks pretty interesting, though pricey. I'm thinking it 
is going to be a development machine as all the switches and display 
would not probably have been on a production machine.


I don't think National made many minicomputer format machines, in 
their history, someone correct me.  That might make this pretty rare 
on that front as well.


thanks
Jim

Beautiful-1974-NATIONAL-SEMICONDUCTOR-COMPUTER-model-imp-16p/
http://www.ebay.com/itm/252700755919



Yeah, it's pretty cool but I don't think the seller has reasonable 
expectations for actually selling it -- the auction started (I believe) 
at $1500 (which may have been a reasonable price), then the seller 
raised it to $2500, now it's at $3500 (which is fairly outrageous, in my 
opinion).  I'm not sure what his strategy is.


Bitsavers has manuals (of course...)

- Josh

Re: National Semiconductor IMP mini

[Josh Dersch]

On 1/2/17 7:58 PM, Brad H wrote:



 Original message 
From: Josh Dersch <dersc...@gmail.com>
Date: 2017-01-02  7:37 PM  (GMT-08:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk@classiccmp.org>
Subject: Re: National Semiconductor IMP mini


On 1/2/17 7:22 PM, jim stephens wrote:

This system looks pretty interesting, though pricey. I'm thinking it
is going to be a development machine as all the switches and display
would not probably have been on a production machine.

I don't think National made many minicomputer format machines, in
their history, someone correct me.  That might make this pretty rare
on that front as well.

thanks
Jim

Beautiful-1974-NATIONAL-SEMICONDUCTOR-COMPUTER-model-imp-16p/
http://www.ebay.com/itm/252700755919


Yeah, it's pretty cool but I don't think the seller has reasonable
expectations for actually selling it -- the auction started (I believe)
at $1500 (which may have been a reasonable price), then the seller
raised it to $2500, now it's at $3500 (which is fairly outrageous, in my

opinion).  I'm not sure what his strategy is.
Bitsavers has manuals (of course...)
- Josh

I think he figured toggle switches and lights = .  He might be correct, 
given the obscene money I've seen laid out just for a PDP 8/e faceplate. You 
never know a) what will motivate a collector and b) when just the right 
collector for a given item will show up.  Every day I thank my lucky stars they 
didn't, for whatever reason, show up for my Mark-8 boards.


With the "No shipping cash on pickup" proviso the seller provides, I 
feel fairly certain no one's biting.  But I've been surprised before...


- Josh

ISO: RL02 cable

[Josh Dersch]

Hi all --

I'm in need of an RL02 cable (drive to drive).  I picked up a second 
drive for my PDP-11/40 and I'd like to get it hooked up.


Thanks as always,

Josh

Re: Pair of Twiggys

[Josh Dersch via cctalk]

On Wed, Mar 15, 2017 at 9:35 AM, Liam Proven via cctalk <
cctalk@classiccmp.org> wrote:

> On 15 March 2017 at 14:17, geneb via cctalk  wrote:
> > Well hooray for Xerox.  Apple still obtained the concepts from Xerox,
> > regardless of the mechanism.
>
> Only some and only very basic ones.
>
> Icons for files, the "OK" and "Cancel" buttons, scroll bars, all kinds
> of utterly basic stuff were invented at Apple.
>

The Star introduced the concept of icons representing files (and other
things) in 1981.  Smalltalk invented scrollbars (they were clumsier than
Apple's though) in the mid 70s.

Also, don't forget that the Mac was designed by a number of ex-PARC
researchers.  It may have been invented at Apple, but it was strongly
influenced by what went on at PARC.

- Josh

Re: Pair of Twiggys

[Josh Dersch via cctalk]

On Wed, Mar 15, 2017 at 10:50 AM, Al Kossow via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 3/15/17 10:40 AM, Josh Dersch via cctalk wrote:
> > the Mac was designed by a number of ex-PARC
> > researchers.
>
> Steve Capps was the only person on the original Mac team who worked at
> PARC.
> They were influenced strongly by the UI and graphics work of Lisa.
>

Wasn't Bruce Horn at PARC (at least as a student?).  But you're right, I
should have specified Mac and/or Lisa...

- Josh



>
> There were several ex-Xerox (PARC and SDD) people on Lisa, Frank Ludolph,
> for
> example, who was an author of the Lisa UI paper I pointed to yesterday.
>
> Jean-Louis Gassée was the person who was the manager of engineering when
> Nubus
> was added to the Mac. He had "Open Mac" as his license plate at the time.
>
> http://kootenaymac.blogspot.com/2016/08/vintage-macintosh-
> 87-open-mac-license.html
>
> https://books.google.com/books?id=ED8EMBAJ=PT20;
> lpg=PT20=%22open+mac%22+license+plate=bl=GNixQxKrJP=a-
> 22GlibEC6GLAUaEZF0PAgP_qU=en=X=0ahUKEwjI5YWGidnSAhWHwVQKHauYC
> e8Q6AEIIjAB#v=onepage=%22open%20mac%22%20license%20plate=false
>
>
>

Re: IBM S/32, PDP-11/60+RL01, PDP-11/34, East Lansing MI

[Josh Dersch via cctalk]

FWIW, the LCM+L inquired and heard back earlier this week, apparently the
gear has been claimed.  Hopefully that's true...

- Josh


On Fri, Mar 3, 2017 at 2:03 PM, Systems Glitch via cctalk <
cctalk@classiccmp.org> wrote:

> > Ditto for one of the people here who said they'd sent the person an email
>
> Whoops, ended up in the spam folder! No, I haven't heard back either. I
> sent a follow-up and CCed the second address in his email. Provided my
> office phone number, no reply or calls.
>
> Thanks,
> Jonathan
>

Re: DEC DW11 information?

[Josh Dersch via cctalk]

On 3/2/17 10:26 PM, Josh Dersch wrote:


On 2/27/17 10:02 PM, Tony Duell via cctalk wrote:

>From memory it handles 18 bit addressing (not 22, of course), 
interrupts and

NPR (DMA). The Unibus side (quad card) goes in any SPC slot, you have to
remove the NPG jumper. It links with a pair of 40 way ribbon cables 
to the
Qbus board (dual height) which goes in the 'first' slot of a Qbus 
backplane,
where the CPU board wound normally go. AFAIK there are no real 
restrictions
on the Qbus backplane, I have used one to hang a MINC chassis off a 
Unibus

processor.

I seems to be transparent in operation. You just acccess Qbus devices 
at their

normal addresses.
Cool.  I managed to snag an M8217+M9403 so all I need to do is track 
down/build some cabling to tie the two together (any idea what the max 
length of these cables is?).  I'm kind of hoping I can use it to run a 
QBus SCSI controller, amongst other things. I'll report back my 
findings...


Just to bring some closure to this thread, I had some time this evening 
to get everything hooked up:  A PDP-11/34 connected to an SB11 QBus 
chassis via a DW11-B.  And I've successfully booted XXDP and Ultrix-11 
from a CMD CQD-200 SCSI controller installed in the SB11.  Seems to work 
perfectly.


Thanks for the input, everyone!

- Josh

PDP-11/34 rails?

[Josh Dersch via cctalk]

Hi all --

I'm looking to rack up my PDP-11/34 so I can get it off my bench.  I'd 
like to track down something similar to (if not exactly) the original 
rackmount rails (the ones that allow the chassis to pivot 90 degrees so 
you can deal with the backplane easily), but I'm not sure what the 
original part number or manufacturer was.  Anyone have this information 
handy?  Better yet, anyone have a spare set of rails handy?


Thanks as always,

Josh

Re: Able board on eBay

[Josh Dersch via cctalk]

I looked it up a couple of days ago.  It's in a brochure on Bitsavers:

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/able/brochures/Able_Computer_Product_Brochures_1982.pdf

See page 12.  It's one part of a DMAX/16.  The same seller had the other
half for sale as well (mislabeled).  Not nearly as cool as an Enable :).

I was bummed I got outbid on the Qniverter the seller had for sale (which
was listed as a "Univerter").

- Josh


On Fri, Mar 3, 2017 at 7:17 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> So there was an odd board from Able up on eBay:
>
>   http://www.ebay.com/itm/311809552775
>
> Anyone know what it was? From the Able product summary it looked a bit
> like an
> Interlink/U or perhaps an Enable - although the detailed chip layout didn't
> look like the illustrations of either. Anyone know?
>
> Also, speaking of the Able ENABLE, I've recently discovered more about it,
> and
> now understand pretty much how it works.
>
> Noel
>

Re: DEC DW11 information?

[Josh Dersch via cctalk]

On 2/27/17 10:02 PM, Tony Duell via cctalk wrote:


On Tue, Feb 28, 2017 at 4:32 AM, Josh Dersch <dersc...@gmail.com> wrote:

Hi all -

Anyone have any technical information (manuals, schematics, etc.) for the
DEC DW11 UNIBUS->QBus interface?  I'm curious to know what it's capable of

I am pretty sure I have the printset for it somewhere. I think the
VS11 prints also
include it (the VS11 is a VSV11 with said interface to allow it to be
used on the
Unibus).
Yeah, the VS11 drawings have the M8217 schematics, so that's useful.  
It'd be nice to find an actual manual, but it's a good start.





and what the requirements are, especially on the QBus side of things.  What
kind of backplane is required?  I assume it doesn't support 22-bit QBus
devices given the age of the interface (and the complexity required to do
so), but does it handle 18-bit devices, or only 16?

>From memory it handles 18 bit addressing (not 22, of course), interrupts and
NPR (DMA). The Unibus side (quad card) goes in any SPC slot, you have to
remove the NPG jumper. It links with a pair of 40 way ribbon cables to the
Qbus board (dual height) which goes in the 'first' slot of a Qbus backplane,
where the CPU board wound normally go. AFAIK there are no real restrictions
on the Qbus backplane, I have used one to hang a MINC chassis off a Unibus
processor.

I seems to be transparent in operation. You just acccess Qbus devices at their
normal addresses.
Cool.  I managed to snag an M8217+M9403 so all I need to do is track 
down/build some cabling to tie the two together (any idea what the max 
length of these cables is?).  I'm kind of hoping I can use it to run a 
QBus SCSI controller, amongst other things.  I'll report back my findings...


Thanks,
- Josh




-tony

Looking for PDP-8 G603 "Memory Selector Matrix" boards (or dec T-2052 transformers)

[Josh Dersch via cctalk]

Hi all --

I recently got insanely lucky and scored a Straight-8 (S/N 14).  It made it
in nearly one piece from Ohio, but during transit, all of the G603 Memory
Selector Matrix boards fell out.  It looks like on early revisions, there
was no bar in place to hold the boards in (or someone removed the bar from
this one, but I see no indications that this was so).  So while the rest of
the flip chips were secured, I overlooked these in guiding the seller in
prepping it for shipping.

Two of the boards sustained pretty major damage, about a half a dozen of
the little "gum drop" looking transformers (DEC refers to them as T-2052)
broke off and most of them fell out and will never be found again.

I realize it's a long shot, but does anyone have:

- Any spare G603s (working or no, as long as the transformers are there)
- Any spare T-2052s (or know of a source)
- Any idea what the T-2052 *was* so I can try to replace them.  I haven't
found much detail as of yet.

(The G603 schematic is here:
http://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/Gxxx/G603/G603E.pdf
)

Thanks, all!
- Josh

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Josh Dersch via cctalk]

On Wed, Aug 2, 2017 at 2:14 PM, Aaron Jackson via cctalk <
cctalk@classiccmp.org> wrote:

> >> On Aug 2, 2017, at 11:32 AM, Aaron Jackson via cctech <
> cct...@classiccmp.org> wrote:
> >>
> >> Hi all,
> >>
> >> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
> >> controllers. I already have two RL02 and packs (which need a clean),
> >> with thanks to Dave Wade on this list.
> >>
> >> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
> >> this is going to be possible. Does anyone know/think otherwise? Maybe by
> >> removing *many* unnecessary and running strip on any binaries left from
> >> my destruction? Ignoring spare for the user, for the time being...
> >>
> >> If not, what other UNIX options are there which I will be able to use,
> >> supporting the DEQNA and running on two RL02 drives?
> >>
> >> Input much appreciated.
> >
> > Here’s what I did (but I wasn’t space constrained as I have the
> equivalant
> > of 4 RP06 drives).
>
> That is huge compared to my total of 20MB! :D
>
> > You’ll likely have to configure the kernel.  This is easiest done within
> an emulator,
> > as it took 24hours on my 11/70.  I decided that the emulator approach
> was best
> > after the 2nd time I screwed it up.  :-/
> >
>
> Thanks for the suggestion. I have been playing with this already. I
> recompiled the kernel and set a bunch of stuff to NO which I knew I
> wouldn't need. It compiled fine, but then said:
>
> base segment is 47232, min is 49152, too small by 1920 bytes.
> System will occupy 175264 bytes of memory (including buffers and clists).
>
>end {0054200}  nbuf {0012134}   buf
> {0035352}
>  nproc {0012122}  proc {0044344} ntext
> {0012124}
>   text {0053240} nfile {0012130}  file
> {0051260}
> ninode {0012126} inode {0012220}  ncallout
> {0012132}
>callout {0025764} ucb_clist {0012140}nclist
> {0012136}
>   ram_size {000}   xitdesc {0012216}  quotdesc
> {000}
>  namecache {0035070}   _iosize {000}  nlog
> {0011206}
>  SYSTEM IS NOT BOOTABLE. 
>
> If anyone can explain what this mean and possibly how to fix it, I'd be
> very pleased.
>

The base segment is too small.  The 2.11BSD kernel is built as a base image
plus a bunch of 8K segments that are overlaid as needed.  Usually what I
end up seeing is that one of the overlay segments is too large rather than
the base being too small.

To fix it, edit the Makefile in your kernel's configuration directory.
There is a line that starts with "BASE=" -- move an .o file from one of the
overlay "OVX=" lines (something larger than 1920 bytes but not TOO big) and
run make again.  You'll probably also end up needing to tweak some of the
overlay definitions... it's a balancing act.

- Josh




>
> > Running on an emulator allows you to “play around” with the configuration
> > and what will and won’t fit.  You’ll likely have to start with a
> configuration larger
> > than your target just to get started (but I haven’t done it in a long
> time so YMMV).
> >
> > That will also tell you what you can reasonably fit on two RL02 drives.
> Also it’s
> > easier to “back up” and start over if you make mistakes (save a version
> of the
> > emulated disk files before making substantive changes and copy them back
> if
> > you screw up).
> >
> > Once you have something working reasonably well, you can transfer the
> “bits”
> > over to your 11’s RL drives though your preferred method.
> >
> > TTFN - Guy
>
> Thanks again,
>
> Aaron.
>

Re: RX8 M8357 Device address.

[Josh Dersch via cctalk]

On Wed, Aug 9, 2017 at 8:00 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

> Hi Lis
>
> It looks like RX8 SEL is not asserted due to the device address not being
> set up on the DIP switches.
>
> Anybody know what they should be set to in terms of switch number,
> depressed/not depressed on side with numbers.


http://bitsavers.trailing-edge.com/pdf/dec/disc/rx01/EK-RX01-OP-001_RX11UM_Nov76.pdf



>
>
> Rod
>
>
> --
> Wanted one pdp-8/i rocker switch leaver to copy.
>
>

TRS-80 Model 16 hard drive replacement woes

[Josh Dersch via cctalk]

Hi all --

Against my better judgement I picked up a TRS-80 Model 16 last week.  
Initially it wasn't working at all, after replacing the Z80 CPU and CTC 
chips and doing a pretty thorough cleaning of the drives it seems to be 
happy.


It came with a 15 meg disk system which isn't faring so well in my 
attempts to get it running again.  This has what I believe is referred 
to as the "Type 2" controller in it 
(http://nemesis.lonestar.org/computers/tandy/hardware/storage/mfm.html) 
with the 8x300 processor.  The original hard drive in the enclosure(a 
Tandon TM-503) is toast.  The bearings are shot, so it sounds like a 
circular saw when running and the drive never goes ready.  I followed 
directions to replace the hard drive and work around the odd 
write-protect modifications (See: 
https://ia601707.us.archive.org/10/items/TRS-80_HD_Bubble_Repair_19xx_-/TRS-80_HD_Bubble_Repair_19xx_-.pdf) 
and after replacing the original drive with a Seagate ST-225, the Model 
16 sees the drive and is happy with it.


However, I'm unable to format it.  The controller doesn't appear to 
actually be laying down a format and attempts to read sectors after 
formatting fail with "ID Not Found" errors.  I've tried several other 
known-working drives (another ST-225, a CDC 94025-51, and an ST-238 with 
the same results.  (And yes, the terminator is present and accounted for 
on all drives.) I've run the Model II/12/16/6000 diagnostics and the 
controller passes with flying colors, as does the rest of the system.


Before I start digging in deeper to figure out what's going on, I'm 
curious if I've missed a step here.  I know I'm not the first person to 
attempt this, anyone have any ideas?


Thanks as always,

Josh

Re: TRS-80 Model 16 hard drive replacement woes

[Josh Dersch via cctalk]

On 8/12/2017 8:45 PM, Fred Cisin via cctalk wrote:


On Sat, 12 Aug 2017, Josh Dersch via cctalk wrote:
However, I'm unable to format it.  The controller doesn't appear to 
actually be laying down a format and attempts to read sectors after 
formatting fail with "ID Not Found" errors.  I've tried several other 
known-working drives (another ST-225, a CDC 94025-51, and an ST-238 
with the same results.  (And yes, the terminator is present and 
accounted for on all drives.) I've run the Model II/12/16/6000 
diagnostics and the controller passes with flying colors, as does the 
rest of the system.


Before I start digging in deeper to figure out what's going on, I'm 
curious if I've missed a step here.  I know I'm not the first person 
to attempt this, anyone have any ideas?


Long shot:
Is this a system (like the 5160), where there are TWO format programs?
1) a physical low-level format done by special proprietary "non-user" 
(unobtanium?) software, followed by
2) a program named "FORMAT" that only sets up the logical structures, 
DIRectory, etc., and assumes that the low level format was previously 
done


THAT would certainly result in the "logical" format program choking on 
"ID not found", when the physical low level format wasn't to it's 
liking. (mutual incompatibility between most computers and controllers)



My aplogies if I'm asking granny whether she knows how to suck eggs. . .


No apologies necessary :).  The Format I'm running is a low-level format 
(I've tried the Xenix "diskutil" program and the format utility included 
in the diagnostic routines) so it should be laying out the sectors...


I did some probing of the write logic this evening with an oscilloscope, 
armed with the service manual.  I found a 74ls54 in the MFM WRITE DATA 
+/- signal path that doesn't appear to be passing anything through.  I 
don't happen to have any spares on hand so it'll have to wait a few days 
before I can replace it, but it seems likely that this is the culprit.  
I'll keep y'all posted.


Thanks,
Josh





Can you read the drive with the bad bearings (with a flux transition 
board?), enough to determine what physical low level format it has?

(any successful track with sector headers)

Re: HP 300-series boot rom archive?

[Josh Dersch via cctalk]

On Mon, Jul 17, 2017 at 8:13 PM, Curator <cura...@hpmuseum.net> wrote:

> I have to agree with Lee's view on the HP300...  THIS is an HP300...
> http://www.hpmuseum.net/display_item.php?hw=116


Yep yep, I replied to Lee (thought I'd replied to the list, apparently I
don't know how that works anymore) and apologized for not being specific
enough :).


>
>
> Now for the HP9000/375 - I've not seen a service manual for the 375 but
> here's a link to the Service Handbook.
>
> http://www.hpmuseum.net/document.php?hwfile=2053
>
> There's a list of hardware related documents in that handbook but there's
> no mention of a Service Manual.  Perhaps it was an unlisted HP internal
> document - but the handbook looks like it has enough for the typical field
> repair efforts of its era..
>

Yep, I found that one, but it's not useful for actually repairing anything
beyond basic board-swapping.


>
> If yours is dead, a bad power supply is the most likely issue.  The same
> power supply was used in the 9000/340 but the 340's service manual doesn’t
> tell you much about the internals of the supply.  The 345 service manual
> tells you more but the supply for that box is a different model.
>

It's not the supply, I've tested the supply, and I've tested the board in
known-working chassis and it behaves identically (all diagnostic LEDs on, a
buzz coming from the speaker, similar to the short one you normally hear at
power-up, but forever.)  It seems like it's probably not coming out of
reset but that's just a guess.

Thanks!
Josh



>
> The supply was most likely sourced from a third party so you might have to
> hunt around for an OEM part number on the unit and maybe get lucky with
> schematics on the web.  Otherwise standard troubleshooting tasks for switch
> mode power supplies would apply..  http://www.repairfaq.org/sam/
> smpsfaq.htm#smpssctos
>
> David Collins
> HP Computer Museum
>
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Lee
> Courtney via cctalk
> Sent: Monday, 17 July 2017 4:36 PM
> To: Josh Dersch <dersc...@gmail.com>; General Discussion: On-Topic and
> Off-Topic Posts <cctalk@classiccmp.org>
> Subject: Re: HP 300-series boot rom archive?
>
> Hi Josh,
>
> "lot of HP 300 gear"
>
> Being picky here, but I worked at HP in the HP 300 days and the system you
> acquired does not sound like an HP 300, aka Amigo (
> https://en.wikipedia.org/wiki/HP_300), but rather a model of HP 9000
> desktop machines (M68K based?).
>
> Lee C.
>
> On Sun, Jul 16, 2017 at 7:50 PM, Josh Dersch via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > Hi all --
> >
> > I picked up a small lot of HP 300 gear yesterday and I'm working on
> > getting them going.  In particular, I have a 9000/350 that I'd like to
> > use but it has what appears to be a very early boot ROM (dated 7/9/87,
> > version
> > A2) and it doesn't recognize the 98658 SCSI controller I'd like to use
> > in it -- it enumerates as "127 at 14" rather than getting a the usual
> > identification.  I'm hoping that later revisions might support this card.
> > (I lack functioning HP-IB storage at the moment).  Is there an archive
> > of ROM images for the 300 series anywhere?  Anyone have a 350 with a
> > later boot ROM they can image for me?
> >
> > (Also, if anyone has a real service manual for the 9000/375, drop me a
> > line -- I have one that's stone dead...)
> >
> > Thanks as always,
> >
> > Josh
> >
> >
>
>
> --
> Lee Courtney
> +1-650-704-3934 cell
>
>

HP 300-series boot rom archive?

[Josh Dersch via cctalk]

Hi all --

I picked up a small lot of HP 300 gear yesterday and I'm working on 
getting them going.  In particular, I have a 9000/350 that I'd like to 
use but it has what appears to be a very early boot ROM (dated 7/9/87, 
version A2) and it doesn't recognize the 98658 SCSI controller I'd like 
to use in it -- it enumerates as "127 at 14" rather than getting a the 
usual identification.  I'm hoping that later revisions might support 
this card. (I lack functioning HP-IB storage at the moment).  Is there 
an archive of ROM images for the 300 series anywhere?  Anyone have a 350 
with a later boot ROM they can image for me?


(Also, if anyone has a real service manual for the 9000/375, drop me a 
line -- I have one that's stone dead...)


Thanks as always,

Josh

Re: HP 300-series boot rom archive?

[Josh Dersch via cctalk]

On 7/16/2017 8:12 PM, Glen Slick via cctalk wrote:

On Sun, Jul 16, 2017 at 7:50 PM, Josh Dersch via cctalk
<cctalk@classiccmp.org> wrote:

Is there an archive of ROM images for the 300 series anywhere?

You probably already found these. Unfortunately the 350 is missing
from the set. The only system I have myself is a 382.

http:/www.bitsavers.org/pdf/hp/9000_300/firmware/



Actually, I hadn't -- I'd looked under the /bits directory, but not in 
/pdf... silly me :).  Thanks for pointing it out, it'll be useful even 
if it doesn't help with the 350.


- Josh

Re: HP 300-series boot rom archive?

[Josh Dersch via cctalk]

On 7/18/2017 10:29 PM, r.stricklin via cctalk wrote:


On Jul 18, 2017, at 8:38 AM, Al Kossow via cctech wrote:


When MAME started supporting the 68K 9000s, I made an effort to go through all 
of my machines
and dump the firmware. I didn't have a 375, which is why it isn't there. It 
would be nice if
some other collectors (Bear?) would dump any firmware out of their machines.

I don't have a 375, but I'll be glad to provide what I can. Having a sense of 
what, specifically, was being sought (and where to send it) would help me focus 
effort.


For my personal needs (which started this thread), I'm looking for a 
later revision of the 350 Boot ROMs (later than A2).  For the 375 I need 
real service docs.


- Josh




ok
bear.

Re: HP 300-series boot rom archive?

[Josh Dersch via cctalk]

On 7/19/2017 10:43 AM, Peter Brown via cctalk wrote:

If yours is dead, a bad power supply is the most likely issue.  The same
power supply was used in the 9000/340 but the 340's service manual doesn’t
tell you much about the internals of the supply.  The 345 service manual
tells you more but the supply for that box is a different model.

I  had a 9000/375 that would not start a couple of years ago - I think that 
there was a coin cell on the motherboard - once this was replaced, the machine 
booted fine.

Peter


Thanks, I gave that a shot.  Unfortunately, it didn't help.  But thanks 
for the suggestion!


- Josh

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

On Wed, Jun 28, 2017 at 11:02 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Josh Dersch
>
> > I pulled the ... bootstrap boards from slot 3 ... The BOOT button
> > causes the RUN light to momentarily flash, but that's about it.
>
> That's not too surprising. The way booting works with the M9301 boot card
> (not
> sure if you know this already; if you do, apologies, and ignore) is that
> the
> 'BOOT' button simulates a power-fail/restart - i.e. it toggles the 'power
> OK'
> line (forget whether it's ACOK or DCOK). When the CPU 'powers up', and
> tries
> to fetch the power fail restart vector from 024/6, the M9301 steps on the
> bus
> address lines and modified the address to 773024/6, which is in the ROM on
> the
> M9301. The new PS/PC retrieved at that point then sends the CPU into the
> ROM.
> So, with no M9301 plugged in, it's not too surprising it doesn't do much.
>

Yeah, I'm aware (or at least was somewhat aware at one point...) of how
this works.  I'm just surprised the CPU upgrade board doesn't do something
similar to provide bootstraps, etc.
(Or maybe it can -- there are a lot of jumpers and dip switches...)


>
> The DEC QBUS processor cards (not sure about the chips themselves) can be
> jumpered on power-up to i) halt, or ii) fetch a PS/PC from 024/6, or iii)
> jump
> to ROM. I've no idea if this board set has something similar (and if so,
> what
> it's set to do).
>
> > Ran the front panel cable to the connector on the CPU board and
> powered
> > it up.
>
> Now I'm confused. There is no cable from the front panel to the CPU in a
> standard 11/34? (There's one from the front panel to the backplane; another
> from the front panel to the M9301; and another from the programmer's front
> panel [if present] to the programmer's front panel board, the M7859; but
> that's it, that I know of.)
>

Front panel to the CPU upgrade, not the original CPU.  If you look at the
pictures I posted, there's a pair of connectors on the CPU board that look
suspiciously like those on the M7859.  There doesn't appear to be an analog
for the M9301 cabling, however.

- Josh



>
> Did you mean the console serial line cable?
>
> Noel
>

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

On 6/30/2017 7:30 AM, Noel Chiappa via cctalk wrote:


 > From: Josh Dersch

 >> Now I'm confused. There is no cable from the front panel to the CPU in
 >> a standard 11/34? (There's one from the front panel to the backplane;
 >> another from the front panel to the M9301; and another from the
 >> programmer's front panel [if present] to the programmer's front panel
 >> board, the M7859

 > Front panel to the CPU upgrade, not the original CPU. ...
 > there's a pair of connectors on the CPU board that look suspiciously
 > like those on the M7859.

Right, that's what's confusing me. I can't work out what you could possibly
be cabling to, on the new CPU board!


There's a 20-pin header on the CPU upgrade board which connects to the 
front panel.  There's also a single 10-pin header whose function I can't 
fathom.




Those two connectors on the M7859 are used only with the 11/34, not the 11/04
(the cable from the M7859 to the programmer's front panel must be there, with
both); they are there for the micro-code single-stepping function on the
11/34, etc. (One cable carries uclock, the other uPC data.)

Since the new CPU probably doesn't have that ability (on the LSI-11 and F-11
chipsets, the micro-word bus is accessible outside the chips, but AFAIK the
same is not true of the J-11), I'm not at all sure what those two connectors
might be.


Yes, the programmer's panel loses most of its functionality (as I'd 
expect, for the reasons you list) but the HALT/SS and BOOT switches are 
functional with the cable connected.   (The ADDRESS/DATA display just 
shows "7" for whatever reason.)  With the 20-pin cable from the front 
panel disconnected, the HALT and BOOT switches are non-functional.




Perhaps they are serial lines using the 'new' DEC standard pinout, which also
use 10-pin headers?


That's possible.   If so, the one on the CPU doesn't appear to conflict 
with the M7856 I already have in the /34.


- Josh



Noel

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

On 7/1/2017 8:59 AM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > So it would appear the upgrade board makes provisions for both
 > situations.

I'm not sure that the two situations that the upgrade board supports are in
fact different, from its point of view. (Assuming that the two situations you
refer to are the two different consoles.) Yes, the _system_ supports two
situations: i) the KY11-LA connecting directly to the backplane, and ii) the
KY11-LB going via the M7859; but the DEC CPUs don't seem to draw any
distinction between the two.

Looking at the KY11-LA prints, the connector to the backplane cable (the one
which is unused with the KY11-LB) carries signals like "Halt Request" and
"Halt Grant", which are generated in the M7859 (which has its own direct
backplane connection) when using the KY11-LB.

So as far as the consoles are concerned, those signals come to the backplane
via different paths, but as far as the CPU is concerned, it sees the same
things through its backplane connection, no matter which is in use - so how
would the upgrade board be any different?


Since I feel like I'm talking to a wall here, let me explain how things 
are set up.


In the original 11/34 configuration you have (from slot 1 on down)
1 - M7266
2 - M7265
3 - M9301/M7859
4 - SPC/MUD

The front programmer's panel is connected via a 20-pin cable to the 
M7859 in slot 3.


With the upgrade installed, you have:

1 - Empty
2 - Empty
3 - Upgrade CPU
4 - Upgrade Memory

The front programmer's panel is connected via a 20-pin cable to the CPU 
in slot 3.


The M7859 is removed from the equation.  There is nothing to provide the 
front panel signals to the backplane, so the header on the CPU board is 
(apparently) used to take care of this.  This is backed up by the 
observation that *if the 20-pin cable is disconnected, the front panel 
does nothing and if it is connected, then the HALT/SS and BOOT switches 
are functional*.  Nothing else on the programmer's panel appears to do 
anything, and that doesn't surprise me.


There is also a 10-pin header on the CPU.  I do not know what it is for, 
but Jerry's suggestion sounds valid.  It does not appear to be a serial 
port; there's nothing that looks like a UART onboard.  I've spent a 
couple of minutes trying to trace things out but I haven't made much 
headway.  This board is dense and multilayer and nothing in the 
immediate area seems to connect to it.




The _only_ cable(s) that ever connect(s) to the CPU board (in the KD11-D or
KD11-E) are from the KY11-LB: those cables are the ones that carry the signals
to support the microcode single-stepping. How would the upgrade board use
these?



Yes, the 11/34 CPU didn't connect to the front panel in any way.  I 
don't understand why this precludes a CPU upgrade that replaces large 
portions of the original hardware from doing so in order to support the 
front panel in a minimal way.





One thing that might help untangle the function of those two headers on the
upgrade board is to look and see what chip(s) they connect to. If they aren't
EIA transmitters/receivers, yes, they aren't serial lines. (I only suggesgted
that because I couldn't figure out what _else_ they could be.) Can that be
done?


See above.

- Josh




  Noel

Informer D304 terminal docs, etc?

[Josh Dersch via cctalk]

Hi all --

I picked up an Informer D304 terminal at VCF West because it was cute 
and cheap.   You can see a picture of this beast on page 3 of:


http://chiclassiccomp.org/docs/content/computing/Informer/Informer_401TerminalBrochure.pdf

I haven't found any real documentation for this terminal, and mine's 
missing the external power supply.  This connects via a 25-pin d-sub 
connector.  I can probably work out what voltages it wants, but if 
anyone has any documentation for this thing (or happens to have a power 
supply they can scope out) please let me know.


Thanks!

Josh

Re: Informer D304 terminal docs, etc?

[Josh Dersch via cctalk]

On 8/8/2017 3:50 PM, Glen Slick via cctalk wrote:


On Aug 8, 2017 3:42 PM, "Josh Dersch via cctalk" <cctalk@classiccmp.org>
wrote:

Hi all --

I picked up an Informer D304 terminal at VCF West because it was cute and
cheap.   You can see a picture of this beast on page 3 of:


You got the one with the monitor on the pole in the left corner? Seems like
poor ergonomics if you actually had to use that much.



Yep, that's the one.  And yeah, it would be pretty annoying to use for 
any serious length of time.  But you have to admit it's interesting 
looking :).


- Josh

Re: RX8 M8357 Device address.

[Josh Dersch via cctalk]

On Wed, Aug 9, 2017 at 9:16 AM, Al Kossow via cctalk <cctalk@classiccmp.org>
wrote:

>
>
> On 8/9/17 8:32 AM, Josh Dersch via cctalk wrote:
> > On Wed, Aug 9, 2017 at 8:00 AM, Rod Smallwood via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >> Hi Lis
> >>
> >> It looks like RX8 SEL is not asserted due to the device address not
> being
> >> set up on the DIP switches.
> >>
> >> Anybody know what they should be set to in terms of switch number,
> >> depressed/not depressed on side with numbers.
> >
> >
> > http://bitsavers.trailing-edge.com/pdf/dec/disc/rx01/EK-
> RX01-OP-001_RX11UM_Nov76.pdf
>
> he asked about the RX8-E
> the maint manual is in http://www.computerhistory.org/collections/catalog/
> 102748557
> if it hasn't been scanned yet
>

The manual I linked contains configuration details for the RX01, RX8E and
RX11.  See page 2-10.

- Josh

Re: pdp-8/e restoration.

[Josh Dersch via cctalk]

On 8/7/2017 3:50 PM, Rod Smallwood via cctalk wrote:




On 07/08/2017 22:52, Ian S. King via cctalk wrote:

On Mon, Aug 7, 2017 at 2:40 PM, Pete Turnbull via cctalk <
cctalk@classiccmp.org> wrote:


On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:

So to-morrow connect up a terminal that will do 110 baud and try an 
echo

test.

Next part is interesting. There should be a way to fake a reader / 
punch

and feed in tape images.


There is.  Look on Kevin McQuiggin's site:
http://highgate.comm.sfu.ca/pdp8/

In the section called "Software", about 1/3 of the way down, look for
send.c or better still new-send.c (I call it rsend, on my system).  You
might also find rim.c and the BIN loader useful.

They're also on my webpage, with the corresponding manpages:
http://www.dunnington.info/public/PDP-8/

That's the easiest place to get the manpages for rim.c, send.c, 
rsend.c.

Here's the gist (top parts of the manpages):

rim - create RIM-format file from ASCII addr/instr
   rim is a very simple converter.  It reads in a file containing two
   columns of ASCII digits; the first column is a list of addresses (in
   octal) and the second is a list of machine instructions (also 
octal).

   Output is a file suitable to feed to the RIM loader on a PDP-8.

send, rsend - send a file in RIM or BIN format to a PDP-8
   send and rsend are utilities to transmit a RIM format or BIN format
   file from a UNIX (or other) host to a PDP-8 over a serial line.  The
   PDP-8 should be running the RIM loader routine prior to starting
   either of these programs.
   Input should be a file in RIM format or BIN format.  Output goes to
   the host serial port, which should be connected via appropriate 
cable

   to the PDP-8.
   send is a simple version, with built-in serial port settings and a
   fixed delay between characters.  rsend is more sophisticated; it can
   be controlled by command-line options or environment variables, and
   can accept input on stdin.

On a Unix (or Linux etc) machine you can pipe the output from rim to
rsend, and if you're using papertape images (of which there are load 
on the

net), rsend can strip the headers for you.

--
Pete
Pete Turnbull


Once upon a time I wrote a Python program to stand in for an ASR-33,
providing both a terminal session and a papertape image reader/punch.
N.B.: much PDP-8 software likes 7E1, but PTR/PTP is 8N1.  ISTR that even
when I fiddled with SLU settings, I couldn't get away from 7E1 for 
some of

the diagnostics.  Of course, I've slept since then.  -- Ian


Thank you that's interesting.
So far to-day I hooked up a three wire RS232 connection to an old 
Compaq notebook and ran msk315 (kermit)

Next SET BAUD 110
Then toggle in the print test on the 8/e.
Yup prints the character set on the notebook
Then echo test - nope.
The M8650 probably needs DTR or whatever.
Three wires was a bit cheeky I guess
In the hardware docs for the 8/e there's a load of info about the 8650.
I'll go read that.


Three wires should be enough, no DTR necessary.  Double-check your 
wiring and the jumpering on the M8650.




One other thing - I have a working TU58.
The two cassette drives in a box type with serial interface.
Now the pdp-8/e DECTapes were also called TU58.


The typical DECtapes used with the PDP-8 were TU56's, a completely 
different (and much more rare) beast.



The M8650 is on the list of what you can connect it to.
So does the one substitute for the other and raise the possibility of 
booting from tape?


No, they're not substitutes.  I'm not aware of any PDP-8 systems booting 
and running from a TU58, but I suppose it's not impossible. Mostly the 
problem with the TU58 at this point is that (a) the capstan rollers in 
your drives are most likely tar, and (b) the rubber parts in the tape 
itself have done the same, and (c) the tape itself probably isn't in 
great shape either.


- Josh



Rod

Re: Booting OS/8

[Josh Dersch via cctalk]

On 8/8/2017 6:40 AM, Rod Smallwood via cctalk wrote:


OK RX8 is in the pdp-8/e connected to the RX01. OS/8 floppy in drive.

All I need is the toggle in bootstrap and you never know.


It's the first hit on google for "RX01 bootstrap."

http://www.pdp8.net/interface/rx01_boot.shtml

- Josh



Rod

Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

Hi all --

Snagged an interesting boardset off eBay last week; it was listed as a 
PDP-11/34 CPU upgrade with no other details.  The set consists of two 
hex-height unibus boards -- the CPU board has a J-11 processor on it, 
the memory board contains 4mb of memory, and there's an interconnect 
cable between the two  Not too shabby.  I cannot find a model name or 
manufacturer printed on it anywhere. "TD104" is silk-screened on both 
boards.  The boards are marked "AH183" and "AH137" on the handle edge.


I've put up a set of pictures at:

https://1drv.ms/f/s!Aqb36sqnCIfMoqF-7tupNHmuXdfguw

Does this look familiar to anyone?  Love to get some more information on 
this before I try to use it, I don't want to put it in the wrong system 
or the wrong slots...


Thanks as always,

Josh

Re: FTGH clear-out at Mesa Electronics, Richmond, CA, USA

[Josh Dersch via cctalk]

On Wed, May 24, 2017 at 9:30 AM, Steven M Jones via cctalk <
cctalk@classiccmp.org> wrote:

> On 05/24/2017 02:16, Pontus Pihlgren wrote:
> >
> > I'm surprised to see a swedish keyboard there :)
>
> And I thought it was important to include that keyboard, because
> somebody somewhere must be in a real jam if they need one...
>
>
> > What is a PCM-12 ?
>
> It appears to be a PDP-8 clone based on the Intersil 6100. I just now
> found this link to a better-preserved example:
>http://www.dvq.com/oldcomp/PCM12/
>
> I've put photos of the unit I picked up here (more link variations from
> Flickr):
> https://flic.kr/s/aHskX3uiy4
>
>
That looks like a cool little machine.  I'm kind of jealous :).  Hope you
can get it running again!

- Josh



>
> --S.
>
>

Re: Ebay - PDP-8/M

[Josh Dersch via cctalk]

That is correct, this is my auction.  If anyone has any questions, drop 
me a line!


- Josh


On 5/26/17 3:35 PM, Ian Finder via cctalk wrote:

I think he may have already picked it up. I believe he is trying to un-pick
it up using eBay.

On Fri, May 26, 2017 at 3:08 PM, Glen Slick via cctalk <
cctalk@classiccmp.org> wrote:


On Fri, May 26, 2017 at 12:05 PM, Anders Nelson via cctalk
 wrote:

Oh boyee:

http://www.ebay.com/itm/112414315290

I thought the M variants all had blank front panels and bootstraps, but
this has all the pretty stuff!


That one is close to Josh, maybe he should pick it up. :) :)

Random musing: VCB02 on VAX-11/750

[Josh Dersch via cctalk]

So I had a random thought in the wee hours this morning and I leave it 
to you, the cctalk braintrust, to tell me exactly how stupid this idea is:


I have a VAX-11/750, an Able QNiverter (UNIBUS->Qbus adapter), a 22-bit 
Qbus backplane, and a VCB02 (QDSS) 4-bit graphics boardset.


Theory: With an appropriately modified NetBSD driver for the VCB02, such 
that it provides only 18-bit addresses to the VCB02's DMA engine, I can 
get X running on the VCB02 on the 11/750.


That is, the configuration is: 11/750->Unibus->QNiverter->Qbus->VCB02.

Obviously the console functionality of the VCB02 won't work since that 
requires support on the VAX side of things that won't be present, but I 
think everything else should work.  I've browsed the technical manual 
and I don't see anything that should get in the way, I'll just need to 
hack up the driver appropriately.


But this is something that randomly popped into my head (I was inspired 
by a research paper, "A VAX Based Data Acquisition Computer System at 
the Nuclear Structure Research Laboratory" wherein a Matrox QRGB Qbus 
graphics board was lashed to an 11/750 in a similar manner...


What say you all?

- Josh

Re: HP 9836 systems and Fuji Pictrography 4000 printer available

[Josh Dersch via cctalk]

On 5/27/17 1:51 PM, Bob Rosenbloom via cctalk wrote:


I looked at the three machines. Two are monochrome and the third has a 
sticker saying it's been upgraded to

an 9836C so that's the one for the color monitor.

Unfortunately, it looks like no one is interested in them so they 
might get scrapped. Oh well... I just don't have

room to keep everything.

Bob




I'm interested in the 9836C, but I won't be down to Santa Cruz for 
awhile; maybe it could be shipped up with the rest of the gear once the 
LCM meets and works the plans?  Would you be willing to hold onto it for 
a little while longer?


Thanks,
Josh

Re: HP 9836 systems and Fuji Pictrography 4000 printer available

[Josh Dersch via cctalk]

On 5/27/17 5:04 PM, Bob Rosenbloom via cctalk wrote:


On 5/27/2017 3:26 PM, Josh Dersch via cctalk wrote:



On 5/27/17 1:51 PM, Bob Rosenbloom via cctalk wrote:


I looked at the three machines. Two are monochrome and the third has 
a sticker saying it's been upgraded to

an 9836C so that's the one for the color monitor.

Unfortunately, it looks like no one is interested in them so they 
might get scrapped. Oh well... I just don't have

room to keep everything.

Bob




I'm interested in the 9836C, but I won't be down to Santa Cruz for 
awhile; maybe it could be shipped up with the rest of the gear once 
the LCM meets and works the plans?  Would you be willing to hold onto 
it for a little while longer?


Thanks,
Josh




Sure, I'll pull it for you. Want any of the printers?


Thanks!  I don't need any of the printers, I'm set :).

- Josh





Bob

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

And to reply to my own post, tonight I took a closer look at the boards and
noted that someone had written "3" and "4" on the CPU and memory board
handles in sharpie.  I checked out the power and ground signals on the card
edges and they match up with a typical MUD slot.  Based on this I felt it
safe to assume that these go in slots 3 and 4 of the 11/34's CPU backplane
(the first two SPC/MUD slots).

I pulled the 11/34 CPU boards in slots 1 and 2, the M7859 and bootstrap
boards from slot 3 and installed the upgrade boards in slots 3 and 4.  Ran
the front panel cable to the connector on the CPU board and powered it up.
 "7" appears on the LED panel and if I hit the "HLT/SS" button I get an ODT
prompt!  The BOOT button causes the RUN light to momentarily flash, but
that's about it.  Not sure what else can be done with the front panel, if
anything, would be nice to find a manual.

At any rate, I've successfully booted 2.11BSD on the upgraded 11/34, and it
seems to work well.  If anyone out there knows more about this boardset,
let me know...

Thanks,
Josh


On Mon, Jun 26, 2017 at 10:58 PM, Josh Dersch <dersc...@gmail.com> wrote:

> Hi all --
>
> Snagged an interesting boardset off eBay last week; it was listed as a
> PDP-11/34 CPU upgrade with no other details.  The set consists of two
> hex-height unibus boards -- the CPU board has a J-11 processor on it, the
> memory board contains 4mb of memory, and there's an interconnect cable
> between the two  Not too shabby.  I cannot find a model name or
> manufacturer printed on it anywhere. "TD104" is silk-screened on both
> boards.  The boards are marked "AH183" and "AH137" on the handle edge.
>
> I've put up a set of pictures at:
>
> https://1drv.ms/f/s!Aqb36sqnCIfMoqF-7tupNHmuXdfguw
>
> Does this look familiar to anyone?  Love to get some more information on
> this before I try to use it, I don't want to put it in the wrong system or
> the wrong slots...
>
> Thanks as always,
>
> Josh
>
>
>

Owens Illinois Digivue technical info

[Josh Dersch via cctalk]

Hi all --

I find myself with an Owens Illinois Digivue plasma display, model 
designation MDXVI.  This appears to be a later model than the ones used 
in the PLATO IV and V terminals and I can't find any real information on 
it.  This one has two D-sub connectors on the rear -- a 15-pin for the 
power supply and a 25-pin for everything else.


Love to know what the interface specs are so I can make the display do 
something interesting.  Schematics would also be nice. Anyone have any 
docs stashed away?


Thanks,

Josh

HP-UX 5.1 for the 9836U?

[Josh Dersch via cctalk]

Hi all --

Anyone have media for the 9836U version of HP-UX 5.1?  The copy on 
hpmuseum.net (http://www.hpmuseum.net/display_item.php?sw=581) only 
works on the 9000/310 and I haven't found much of anything anywhere else.


Thanks as always,

Josh

Re: Why women were the first computer programmers

[Josh Dersch via cctalk]

On Thu, Aug 24, 2017 at 3:11 PM, Jay West via cctalk 
wrote:

> Several wrote...
>
> > You may feel free to remove me from this list.
> And
> > Likewise.
> And
> > That's it for me and this list.
>
> I did not say sexism was ok. Those that are reading that in to it - please
> click unsubscribe as you are obviously looking for an excuse to do so
> regardless. Or perhaps you're upset I won't give you a soapbox to
> commandeer the list discussion. Either way - please leave.
>
> Please note that I said to keep things in a historical perspective and
> on-topic. I don't think that is saying sexism is ok.
>
> On a technical list with adults, I believe that when someone posts
> something on-topic which has portions you do not personally like that
> perhaps the adult thing is to take the points that are in-common and expand
> on them, leaving the points behind that you find offensive or
> inappropriate. The rest will be dealt with off-list, as I have done in the
> past.
>
> While one could argue about the intent of the original poster, one cannot
> argue that the personal attack - and namecalling - from Evan was
> acceptable. It was not.
>

Evan wasn't namecalling.  He pointed out that Rod's statement was sexist
and crude.  It wasn't a personal attack.

Your statement about "the world going mad with political correctness"
speaks volumes.  This also isn't a personal attack.

- Josh



>
> J
>
>
>
>

Re: Why women were the first computer programmers

[Josh Dersch via cctalk]

On Thu, Aug 24, 2017 at 2:12 PM, Jay West via cctalk 
wrote:

>
> It was written...
> ---
> That's crude, ignorant, sexist, and wrong.
> ---
>
> The above statement sounds to me as being intolerant, hatespeech, and
> judgemental. Why do you think you have the right to determine that and
> apply labels to someone?
>

It's none of the above.  Why does Rob have the right to label all women as
incapable of doing the same job as a man?



>
> The world has gone mad with political correctness, and I will - at least
> in the very tiny corner of it that I control - not allow it.
>

You may feel free to remove me from this list.

- Josh


>
> Feel free to continue this discussion, but keep it to historical
> perspective and on-topic. If I see even one post that is attacking someone
> personally or politically, the list will go into emergency moderation mode.
> I will not allow political BS (nor personal attacks) here.
>
> J
>
>
>
>
>

Re: Why women were the first computer programmers

[Josh Dersch via cctalk]

On 8/23/2017 9:14 PM, Rod Smallwood via cctalk wrote:




On 24/08/2017 04:10, Brian Walenz via cctalk wrote:
On Wed, Aug 23, 2017 at 8:59 PM, Al Kossow via cctalk 

Interdata 70 front panel keys

[Josh Dersch via cctalk]

Hi all --

Got an Interdata Model 70 here (well, the parts to build one, anyway) 
missing the front panel key.  Anyone (a) got a few spares lying around 
or (b) have key codes for this thing?


Thanks,

Josh

Re: DEC indicator panel mounting details

[Josh Dersch via cctalk]

On Tue, Dec 19, 2017 at 2:15 PM, Al Kossow via cctalk  wrote:

>
>
> On 12/19/17 10:49 AM, Noel Chiappa via cctalk wrote:
>
> > Could someone who has one please take a look and let us know (or, even
> better,
> > send us photos)?
>
>
> If someone can't get to mounted ones, I can trundle over to CHM artifact
> storage
> and look at one of our racks.
>
> I would think LCM should have some readily accessable, though.
>
>
>
I will see if I can grab some pictures this afternoon. We have a few
cabinets that I can take a close look at the innards of.

- Josh

Re: MicroVAX I Diagnostic floppies

[Josh Dersch via cctalk]

Well, that figures.  Found them here, for future reference:

https://www.headcrashers.org/comp/rx50/index.html

- Josh

On Tue, Dec 19, 2017 at 10:50 AM, Josh Dersch <dersc...@gmail.com> wrote:

> Hi all --
>
> I'm attempting to resurrect a MicroVAX I (because it's there, that's why)
> and the CPU appears to have developed a fault.  Microverify passes at
> powerup, but I can't get VMS to boot (it dies with a SYSBOOT-F-Unexpected
> Machine Check almost immediately).  Also tried Ultrix and it dies shortly
> after enumerating disks.  I know the memory and disk controllers are fine,
> and there's nothing else in the system at the moment, so unless anyone has
> any bright ideas, I think I'm going to need to debug the CPU.
>
> I'm trying to track down the diagnostics for this machine, no luck so
> far.  Anyone have a copy sitting around somewhere?  I believe there were
> two RX50 floppies for this purpose, DEC part numbers BL-T856A-DE and
> BL-T857A-DE.
>
> Thanks as always,
> Josh
>

MicroVAX I Diagnostic floppies

[Josh Dersch via cctalk]

Hi all --

I'm attempting to resurrect a MicroVAX I (because it's there, that's why)
and the CPU appears to have developed a fault.  Microverify passes at
powerup, but I can't get VMS to boot (it dies with a SYSBOOT-F-Unexpected
Machine Check almost immediately).  Also tried Ultrix and it dies shortly
after enumerating disks.  I know the memory and disk controllers are fine,
and there's nothing else in the system at the moment, so unless anyone has
any bright ideas, I think I'm going to need to debug the CPU.

I'm trying to track down the diagnostics for this machine, no luck so far.
Anyone have a copy sitting around somewhere?  I believe there were two RX50
floppies for this purpose, DEC part numbers BL-T856A-DE and BL-T857A-DE.

Thanks as always,
Josh

Re: DEC indicator panel mounting details

[Josh Dersch via cctalk]

On Tue, Dec 19, 2017 at 2:25 PM, Josh Dersch <dersc...@gmail.com> wrote:

> On Tue, Dec 19, 2017 at 2:15 PM, Al Kossow via cctalk <
> cctalk@classiccmp.org> wrote:
>
>>
>>
>> On 12/19/17 10:49 AM, Noel Chiappa via cctalk wrote:
>>
>> > Could someone who has one please take a look and let us know (or, even
>> better,
>> > send us photos)?
>>
>>
>> If someone can't get to mounted ones, I can trundle over to CHM artifact
>> storage
>> and look at one of our racks.
>>
>> I would think LCM should have some readily accessable, though.
>>
>>
>>
> I will see if I can grab some pictures this afternoon. We have a few
> cabinets that I can take a close look at the innards of.
>
> - Josh
>
>
>
See the pictures at the below link:

https://1drv.ms/f/s!Aqb36sqnCIfMotpQIuc2-tDUva3iBw

It looks to be fairly straightforward; the plastic "ball on post" brackets
are mounted to the rack rails, and there are metal brackets that screw into
the BOP brackets that hold the PCB/lamp assembly.

Hope this is the right assembly for you, if not, or if you have questions,
let me know and I can try to fill in the holes...

- Josh

Re: HP 9836U processor mystery...

[Josh Dersch via cctalk]

On 11/8/2017 2:31 AM, Tony Duell wrote:


On Wed, Nov 8, 2017 at 7:05 AM, Josh Dersch <dersc...@gmail.com> wrote:

On 11/6/2017 8:59 PM, Tony Duell wrote:

What BOOTROM version do you have in your machine?  I have 4.0, I'm curious
if there's a later version.

Mine is 4.0

-tony



Found a doc on Bitsavers 
(http://bitsavers.org/pdf/hp/9000_200/9000-200_periphSupp_Dec89.pdf, see 
page 4-2's footnotes) that indicates that there were two variants of the 
9836U -- the earlier with the 12.5Mhz 68000, the later with a 68010.  
Apparently the processor difference wasn't enough to require a model 
designation of its own.


Apparently what I want for my system, HP-UX-wise is version 2.1. 5.1 
just hangs after loading the kernel (no diagnostics) with either 
processor, I assume the processor board itself must have some revisional 
differences.  Maybe someday I'll track that down...


- Josh

Re: Powering Sun 3/60 without a chassis was Re: Sun 3/50 processor board and unknown processor

[Josh Dersch via cctalk]

On 11/21/2017 9:04 AM, Charles Dickman via cctalk wrote:


On Tue, Nov 21, 2017 at 1:51 AM, Mattis Lind  wrote:


I think this is a 3/60 processor. Not 3/50.

I said 3/50 because that is what the silkscreen says. I found some
picture online and the 3/50 was a different layout. It sure looks like
a 3/60


The silkscreen reads "3/60" as clear as day...



Looking at some online schematics it looks like the P3 96 pin DIN
connector may only be for power. Is it possible to power this thing
through that connector without a proper chassis?


Don't see why not.  You'll need to rig up the proper connection with 
some eurocard connectors, and provide a decent supply (I can't find any 
solid info, but I'd wager between 5 and 10A for +5v).


- Josh



I know nothing about Sun hardware.

-chuck

Re: Almost PDP 11/05 on Ebay

[Josh Dersch via cctalk]

On Tue, Nov 21, 2017 at 10:25 AM, william degnan via cctech <
cct...@classiccmp.org> wrote:

> This looks to me like the power supply and backplane of a PDP 11/05, looks
> to be in nice shape.  Surprised no one grabbed this yet, esp someone with
> an 11/05 that has issues with power supply.  Someone might have the missing
> parts.
>
> "DEC PDP-11 Digital BA11-KE Mounting Box"
>
> https://www.ebay.com/itm/DEC-PDP-11-Digital-BA11-KE-
> Mounting-Box/28265372079



It looks to me like a standard Unibus expansion chassis (a BA11-KE, as the
auction says) with a 9-slot DD11-D backplane and a pair of 4-slot
backplanes (not sure what they are, they may also be DD11's, I'm not good
at identifying them from the back ;)).  It could potentially be for an
11/05, but only if that 9-slot backplane isn't a DD11-D and is instead the
special backplane for the 11/05 CPU set...

- Josh


>
>
> granted "all you need are the cards and the front panel" reminds me of the
> steve martin routine.  "It's easy to be a millionaire, first get a million
> dollars and then "
>
> Compare with
> http://vintagecomputer.net/browse_thread.cfm?id=622
>
> b
>

Re: HP 9836U processor mystery...

[Josh Dersch via cctalk]

On Mon, Nov 6, 2017 at 8:59 PM, Tony Duell <ard.p850...@gmail.com> wrote:

> On Tue, Nov 7, 2017 at 4:52 AM, Josh Dersch via cctalk
> <cctalk@classiccmp.org> wrote:
>
> > I'm curious if other people out there with 9836U's can confirm whether
> their
> > machine has a 68000 or a 68010 in it, I'd just like to settle the
> internet
> > discrepancy once and for all :).
>
> Mine identifies the CPU as a 68010 in the power-on diagnostic. But from
> what
> I remember the PGA socket could also take a 68012 (with extra address pins
> brought out). I don't have such a chip, so no idea what it would identify
> as.
>

I picked up a 68012 (cheap) and stuck in in the 9836U this evening.  It
works, and is identified as a 68012 during power-up diagnostics.

So now we know.  Now what am I gonna do with all that address space? :)

- Josh



>
> -tony
>

HP 9836U processor mystery...

[Josh Dersch via cctalk]

Hi all --

I mentioned a few weeks back that I picked up an HP 9836CU workstation.  
The "U" variant differs from the normal 9836 in that it contains an 
upgraded CPU board that allows it to run early versions of HP-UX.  (The 
"C" indicates that this machine has a color display, which is also cool 
but not what I want to talk about here today.)


Information on the Internet varies about what microprocessor the 9836U 
actually contains -- some sources say it's a 12Mhz 68010, some say it's 
a 12Mhz 68000.  I found some internal HP marketing text that 
corroborates the straight-68000 story.  I'd link it here, but 
hpmuseum.net appears to be having technical issues at the moment.


My 9836CU has the 12Mhz 68000 (HP internal part number 1820-3288) fitted 
in a socket on an 09836-66511 board (with the expected 16K SRAM cache 
and MMU logic) and the processor is identified at power-up as a 68000.


Just for fun, I swapped the processor with a PGA 68010 and it powers up 
and runs just fine, and identifies the processor as a 68010.  (Still 
won't boot the copy of HP-UX 5.0 on the hpmuseum site, though...)


I'm curious if other people out there with 9836U's can confirm whether 
their machine has a 68000 or a 68010 in it, I'd just like to settle the 
internet discrepancy once and for all :).


- Josh

Re: HP 9836U processor mystery...

[Josh Dersch via cctalk]

On 11/6/2017 8:59 PM, Tony Duell wrote:


On Tue, Nov 7, 2017 at 4:52 AM, Josh Dersch via cctalk
<cctalk@classiccmp.org> wrote:


I'm curious if other people out there with 9836U's can confirm whether their
machine has a 68000 or a 68010 in it, I'd just like to settle the internet
discrepancy once and for all :).

Mine identifies the CPU as a 68010 in the power-on diagnostic. But from what
I remember the PGA socket could also take a 68012 (with extra address pins
brought out). I don't have such a chip, so no idea what it would identify as.

-tony



Interesting.  So it looks like either processor was possible for the U 
variant.  (With a 68012 as a possibility as well.)


hpmuseum.net is back up; here's the document I was referring to that 
mentions the 68000, see page 16: 
http://www.hpmuseum.net/pdf/ComputerNews_1983_Dec1_37pages_OCR.pdf


What BOOTROM version do you have in your machine?  I have 4.0, I'm 
curious if there's a later version.


Thanks,
Josh

Re: Any difference between VAX Q-bus and PDP-11 Q-bus cards?

[Josh Dersch via cctalk]

On 12/6/2017 6:55 PM, Jon Elson via cctech wrote:


On 12/03/2017 10:28 AM, Aaron Jackson via cctech wrote:

I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
(M5976). If the card did not have the large metal face, would it work in
a Q-bus PDP-11? We are not going to potentially ruin a card by trying
this, but I am interested to know if this is the case.


As long as the PDP supports the 22-bit Q-bus, it should work 
perfectly.  The metal plate can be removed.


Jon



The board will probably work in a 22-bit Q-bus, as you say, but only for 
certain values of "work" -- it won't catch fire or anything, but to the 
best of my knowledge the M5976 isn't an MSCP device and I don't know 
that any PDP-11 bootstraps or OSes know how to talk to it.  So unless 
you want to write a driver for it, it's probably not going to be much use.


- Josh

Re: Which Dec Emulation is the MOST useful and Versatile?

[Josh Dersch via cctalk]

On Wed, Oct 25, 2017 at 5:20 AM, william degnan via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, Oct 24, 2017 at 11:26 PM, Evan Koblentz via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > Related to DEC emulation: is there a visual Straight-8 simulator? I'd
> like
> > to practice working the front panel and such.
> >
>
> I don't think there is one.  The PDP 8i is the closest thing but there are
> I think 26 switches at the bottom the 8i, I think only 18 at the bottom of
> the straight 8.


Both the 8/i and the Straight-8 have the same number of switches (26).
Their function is identical.  The 8/i has a few additional lights, however.

- Josh



> They thus can't be the same exactly but it may be that the
> straight 8 is the same as the 8i, if you use only switches that appear on
> both systems (no step counter on the straight 8).  Dave G will know.
>
> b
>

ISO: DECtape controller

[Josh Dersch via cctalk]

I was fortunate enough to acquire a TU56 this week, along with a TD8E 
controller.  However, the TU56 lacks the G888 flip-chips necessary to 
work with the TD8E; I know these parts are in short supply, but in the 
unlikely event that anyone has (a) a set of 5 G888 boards, or (b) a 
TC01, TC08 or TC11 DECtape controller in any condition that they would 
be interested in selling/trading for, please drop me a line.


Thanks as always!

Josh

ISO: DD11-DF backplane

[Josh Dersch via cctalk]

Hi all --

I finally tracked down the EIS option for my 11/40 and I have it up and
running nicely (Ultrix-11 ATM, but I'll be playing with other stuff).
Right now I only have a 4-slot DD11 backplane for SPC/MUD boards and I'd
like a bit more space for expansion.

I have a few DD11-DK backplanes but without modifying the cabling it won't
work in a BA11-F chassis.  If anyone has a DD11-DF they'd be up for trading
for the -DK variant (or for something else) please drop me a line.

Thanks!
Josh

Re: ISO: DD11-DF backplane

[Josh Dersch via cctalk]

On Wed, Jun 6, 2018 at 3:06 PM, Bill Degnan  wrote:

>
>
> On Wed, Jun 6, 2018 at 5:20 PM, Josh Dersch via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Hi all --
>>
>> I finally tracked down the EIS option for my 11/40 and I have it up and
>> running nicely (Ultrix-11 ATM, but I'll be playing with other stuff).
>> Right now I only have a 4-slot DD11 backplane for SPC/MUD boards and I'd
>> like a bit more space for expansion.
>>
>> I have a few DD11-DK backplanes but without modifying the cabling it won't
>> work in a BA11-F chassis.  If anyone has a DD11-DF they'd be up for
>> trading
>> for the -DK variant (or for something else) please drop me a line.
>>
>> Thanks!
>> Josh
>>
>
> Josh,
> Did you pull the Ultrix-11 from an image or make it yourself.  I'd love to
> get a copy of this if you're able to image and post to the web, and I am
> sure simH folks could use this too.
>

I built it from the tape images on TUHS on SIMH and wrote it out to a real
disk (cheated, since I'm fortunate enough to have a UNIBUS SCSI controller
to play with).  I'm happy to share it out, though it's not too hard to do
manually -- there's a writeup at
https://minnie.tuhs.org/Archive/Distributions/DEC/Ultrix-11/Fred-Ultrix3/setup-3.1.txt
that covers the basics.


> Glad to to hear you were able to get this running with the EIS, I was
> unsure if it was possible.  How much RAM do you have?
>

I have 128KW of MOS memory in the system (wish I had core, but I'll take
what I can get).  Ultrix runs fine, but it's tight and the lack of separate
I+D spaces means some programs won't fit (vi, for example).  I did manage
to build a kernel with TCP/IP and Ethernet included, but I need the larger
backplane in order to install the Ethernet controller to test it :).


>
> I will check to see if I have the backplane.
>

Thanks!

- Josh


>
> Bill Degnan
>
>

Re: non-PC Floppy imaging

[Josh Dersch via cctalk]

On Fri, Jan 5, 2018 at 11:52 AM, Guy Sotomayor via cctalk <
cctalk@classiccmp.org> wrote:

> Hi,
>
> I now have a number of uCode diskettes for my IBM 4331.  I would somehow
> like to image them so:
> a) I have backups in case the floppies themselves go bad
> b) be able to investigate their contents in case I have to “merge” the
> contents of multiple floppies to
>  make a single good one
>
> These are all 8” diskettes.
>
> The complicating factors in all of this are:
> a) any text (e.g. strings) are going to be in EBCDIC rather than ASCII
> b) each uCode diskette was presumably serialized to the CPU it was for
> c) not sure what the “on-disk” structure looks like
> d) the only 8” diskette drives that I have are in IBM (non-PC) equipment
>
> Any ideas/comments would be welcome.
>


As far as backing up the floppies, I used ImageDisk with an 8" Shugart 850
hooked up to a PC to image and duplicate the microcode floppies for the
43xx machines we have at the museum.  It works quite well.  Obviously this
would require you to pick up a "new" 8" drive (I've no experience with IBM
8" drives, but I wager they're not going to "just work" with a PC FDC.)

The IMD tools come with an image viewer that can translate EBCDIC, though
you'll probably want something more advanced to actually modify/splice
things.

- Josh


>
> Thanks.
>
> TTFN - Guy
>
>

Re: Restoring a VT50 (VT52 actually) .

[Josh Dersch via cctalk]

On 12/23/2017 5:34 AM, Mattis Lind via cctalk wrote:


2017-12-23 13:32 GMT+01:00 Mattis Lind :


Yes, the oscillator seems to work. But it is a pain to work with the VT52
since the print set has very little information. Where is the component
list? I cannot verify which PROM should go into what location. And the damn
boards doesn't have any component designator anywhere, nor is there
anything on the component placement info in the print set on the data path
board.

The PROMs in my machine are: 23-124A9, 23-125A9, 23-126A9 and 23-127A9. Is
this the same as your VT52? Apparently there is an earlier PROM set as
well.

It would be very nice if you could tell me the location of the PROM chips
as well.

/Mattis


I did some more research into the terminal after I put the christmas ham
steak into the oven and christmas rice pudding on the stove.

There were nothing going on at the microprogram outputs. All high. It
turned out that the CE input for the PROMS was high for ALL banks!
Impossible! A 7400 at E34 was not doing well. After replacing that there
are some life in the microprogram and I have some random klicks from the
key klick relay. But still not working as it should. So more interesting
fault finding ahead! 20+ years sitting in a cold attic probably is not good
at all.


I've been tinkering with a VT52 at the museum.  I found that the sockets 
for the PROMs are of poor quality and were not making good connections.  
This may not be a problem in your case, but it's something to take a 
look at if you haven't already.


- Josh







 cheers,
   —FritzM.

Help identifying IC

[Josh Dersch via cctalk]

Hi all --

I picked up this little toy at VCF West last summer:

https://1drv.ms/i/s!Aqb36sqnCIfMouYd0HV0ZThE3FnE_Q

As far as I can tell, it's supposed to be a clock and I assume it was a 
kit -- this one was definitely hand-assembled.  It's powered by two AA's 
(apparently, there are no markings), has a 4 digit LED display, and at 
the moment it does not work at all.


Can't find anything about this item at all.  At the moment I'm curious 
what the 28-pin IC at the top is -- there are no markings of any kind 
anywhere on the chip.  It has an interesting construction -- blue 
plastic on both sides with a metal cap over the die.  The two other ICs 
are RCA 3081 and RCA 3082 which are simply transistor arrays for driving 
the 4-digit LED display.  I assume the 28-pin IC is a simple 
microcontroller with built-in ROM, or perhaps it's a device specifically 
designed to run a digital clock.  Whatever it is, I'd love to know what 
it does so I can debug this thing and possibly source a replacement.


I realize this is not a lot of information to go on, but on the 
off-chance someone's seen something like this before I figured I'd give 
it a go...


Thanks,

Josh

ISO: TIPL757A transistor or equivalent

[Josh Dersch via cctalk]

Hi all --

I'm in the middle of repairing a console for a Symbolics 3640.  This uses
the earlier Phillips-based monitor and it employs a TIPL757A transistor in
the deflection circuit.  The one in mine is toast and I haven't been able
to find a suitable replacement.

The datasheet (or at least a page of it) is here:
http://pdf1.alldatasheet.com/datasheet-pdf/view/108034/TI/TIPL757.html

The base current rating seems to be important in this application; I tried
replacing it with a BUX48 (which meets the other specs but only has a 4A
continuous base current rating) and it blew in a few minutes.  I haven't
found a source of 757As, and I haven't found another TO-3 transistor that
matches its specifications.

If anyone's sitting on a pile of these, knows a good source for them, or
knows of a transistor to substitute, please let me know.

Thanks!
Josh

Re: IBM 9331-011 8" External Floppy Drive - eBay 183038271095

[Josh Dersch via cctalk]

On Thu, Feb 1, 2018 at 1:08 PM, Paul Berger via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 2018-02-01 3:43 PM, Ali via cctalk wrote:
>
>> This was dressed to go with the AS/400 line.  Mine is dated 1994.
>>>
>> Anyone know how easy it is to adapt one of these to work with an IBM PC
>> compatible class machine? I have one sitting around here somewhere and if I
>> recall correctly the drive is a bog std. YE-DATA DS 8" drive so it should
>> be just a matter of making sure the cabling is ok.
>>
>> The drives that where used on the AS/400 are all "industry standard"
> drives so it should be easy to adapt one to a PC.
>
> Paul.
>


This is true.  I have the pinouts at home if anyone wants them, I can post
them when I get home from work.  However: I will note that the YE-DATA 8"
drives have heads that are rough on some 8" media, particularly those prone
to shedding.  The heads are also a pain to get to to clean after such
shedding has taken place.  I've stopped using mine for 8" archival for this
reason.  The Shugart 850/851s are much nicer in this regard (Al suggested
them to me awhile back) -- easier on disks, much easier to clean.

- Josh

Re: IBM 9331-011 8" External Floppy Drive - eBay 183038271095

[Josh Dersch via cctalk]

On 2/1/2018 2:52 PM, Ali wrote:


This is true.  I have the pinouts at home if anyone wants them, I can
post them when I get home from work.

Josh,

That would be great. Thanks.

-Ali


.



Here's what I have, from notes I took about 10 years ago when I built a 
cable after beeping things out.  The YE-DATA drive itself uses the 
standard Shugart interface, IIRC. The below table lists the 50-pin edge 
connector pins of interest, the 37-pin d-sub on the back of the drive 
unit, and the 34-pin PC floppy cable.  I make no guarantees, but it 
worked for me:


50-pin edge       37-pin Dsub        34-pin edge
---       ---        ---
1             20                    GND
2             2                       (TG43)
9             25                    GND
10                7                     N/C
11                37                    GND
12                19                    34    (Ready)
13                36                    GND
14                18                    32    (Side1)
17                28                    GND
18                10                    16    (Motor ON/Load)
19                24                    GND
20                6                     8    (Index)
21                27                    GND
22                9                     N/C
25                26                    GND
26                8                     12    (DS1->DS0)
33                29                    GND
34                11                    18    (Direction)
35                30                    GND
36                12                    20    (Step)
37                31                    GND
38                13                    22    (Write Data)
39                32                    GND
40                14                    24    (Write Gate)
41                33                    GND
42                15                    26    (Track 0)
43                34                    GND
44                16                    28    (Write Protect)
45                35                    GND
46                17                    30    (Read Data)

ISO: PDP-11/24 SLU bulkhead

[Josh Dersch via cctalk]

Hi all --

Finally got around to fixing the H777 supply in my 11/24 (in the "L-box" 
BA11-L chassis) and now I'm looking at getting it to do something.  
First order of business is getting the console SLU hooked up, and I'm 
missing the bulkhead panel for it.  There's a 20-pin ribbon cable that 
runs from the CPU backplane to this panel, which breaks it out into two 
25-pin D-sub serial ports. According to the schematics, this is P/N 
54-14218.


Anyone have one of these lying around?  Otherwise I'll just build 
something of my own...


Thanks,

Josh

Re: Bendix G-15 [was: Re: VCF PNW 2018: Pictures!]

[Josh Dersch via cctalk]

On 2/18/2018 11:30 AM, Mark Linimon via cctalk wrote:


On Sun, Feb 18, 2018 at 01:04:38PM -0600, Jon Elson via cctalk wrote:

Wow, even a Bendix G-15 in there (although with Control Data logo).

Nope, look again, there are two :-)


Small correction: there are three -- two upstairs, one in the basement 
(with CDC badging) :)


- Josh

ISO: Tektronix 4404 peripherals

[Josh Dersch via cctalk]

Hi all --

I'm working on fixing up a Tektronix 4404 workstation (runs 
Smalltalk-80!).  Or rather, I'm trying to collect the needed parts to 
assemble a complete system so that I might fix up said system -- at the 
moment I have only the main CPU unit (but hey, it's a good starting 
point).  I am looking for:


- Keyboard (Tektronix P/N 119-1872-00)

- Mouse (Logitech P7-3F-TX-19-1808-00).  This is likely a standard 
3-button quadrature mouse but if I can find the exact match, so much the 
better...


- Mass Storage (Tektronix model 4944, possibly others?  This is a SCSI 
device containing a hard drive on a SCSI->MFM bridge and 5.25" floppy 
drive on a custom SCSI->floppy interface.)


If anyone happens to have spares or knows anyone who might, please let 
me know.  Thanks as always!


- Josh

Re: Miss categorized DEC box on ebay

[Josh Dersch via cctalk]

The DIGITAL logo is visible on the inset portion of the panel next to the
switches (it is a bit blurry).  Further, this matches up with Mattis's
picture quite nicely.

It's an interesting shade of blue, but people have been known to repaint
things...

This looks like a DEC system to me.

- Josh


On Thu, Dec 21, 2017 at 12:08 PM, Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> Further comment.  Notice the difference in height compared to a standard
> DEC box of that style.  Also notice he is holding up the #150 box with his
> fingers.  Remind me never to arm wrestle that guy.
> Personally, I don't think it is a DEC system at all.
>
> bill
>
> 
> From: cctalk  on behalf of jim stephens
> via cctalk 
> Sent: Thursday, December 21, 2017 3:00 PM
> To: cctalk@classiccmp.org
> Subject: Re: Miss categorized DEC box on ebay
>
>
>
> On 12/20/2017 10:27 PM, Bob Rosenbloom via cctalk wrote:
> > PDP 11/03? LSI-11?
> >
> > Maybe someone can use it. Nice blue color.
>
> > VINTAGE-DIGITAL-INSTRUMENTS-COUNTER-HG-ELEMENTS/
> > https://www.ebay.com/itm/302392510749
> >
> > Bob
> >
> The ad says it weighs 150#  That box is heavy, but is not a 150# item.
> I suspect there is more to it.  There seems to be cables
> going out of the back, perhaps to something else for the instrument.
>
> thanks
> Jim
>

Re: Pdp 11/34 System for sale in Riverside,ca

[Josh Dersch via cctalk]

On Wed, Aug 1, 2018 at 8:32 AM, Wayne S via cctalk 
wrote:

> http://www.ctonlineauctions.com/detail.asp?id=746466
>
> From the pictures it looks to be a fairly complete system with Kennedy
> tape drive.
> Has a System industries controller but doesn't appear to have a disk drive.
>

There is a a drive -- big old Fujitsu SMD drive below the SI controller.
I'm guessing a M2284 or similar.


>
> I'd  love to have it, but my wife would kill me if i brought something
> that big home.
> I hope someone in the Riverside area on this list ( Mark Blair ? ) can
> acquire it.
>

It's a nice system, I hope someone can save it.

- Josh



>
> I have no affiliation with the seller.
>
>
> Wayne
>
>

ISO: Scan of IASIS ia-7301 ("Computer In A Book") manual / text

[Josh Dersch via cctalk]

Hi all --

I picked up a nice IASIS ia-7301 (see:
http://www.old-computers.com/museum/computer.asp?c=544;) recently.  It came
with the binder and the computer but none of the paper bits.  Does anyone
have the manual scanned (or is there anyone who might have a copy to
scan)?  I'd like to print a copy to put in there.  My searches on the 'net
have come up empty.

Thanks as always,
Josh

Re: MicroVAX I

[Josh Dersch via cctalk]

On 8/14/2018 2:12 PM, Ethan Dicks via cctalk wrote:


On Sun, Aug 12, 2018 at 11:36 PM, robertbeauchamp33--- via cctalk
 wrote:

My mother is moving and her spouse has a MicroVax I he bought new back in 1984 
for some crazy amount. I don’t see this model listed in your chart? Can you 
tell me if there is any value to this machine? He also has two original 
monitors.

There is some value, since it's in a BA23 and _is_ a VAX, even as slow
as can be.  They are somewhat uncommon because they were only
available for a couple of years unlike most other DEC machines.
Having used one in the mid-80s when they were brand new (and $10,000),
they are quite slow and painful and limited to, I think, various
versions of MicroVMS and VMS 4.x, depending on disk size (MicroVMS
fits on a 30MB disk when the full version would not).  I don't recall
if there is any support for them in VMS 5.x - the max RAM is 4MB
(unlike later Qbus VAXen, the RAM is _on_ the Qbus) but one could
easily put a newer disk controller in there other than the RQDX1 and a
larger disk.


Be aware that most (if not all?) QBus SCSI controllers appear to be 
incompatible with the MicroVAX I.  I'm not entirely sure why this is, 
but none of the Emulex, CMD, or Dilog controllers I've tried are listed 
as compatible with the system -- they all state compatibility with the 
II and later .I've tried using them in my MicroVAX I with no success.  
VMS fails to boot, and Ultrix kernel panics.  Not to hijack the thread, 
but does anyone have any idea why this might be? I'd like to get the 
system doing something interesting and not having to rely on very old 
MFM disks would be nice...


- Josh


As shipped, though, I don't think the uVAX-I arrived
with a large enough disk for VMS 5.0, at least not without a very
manual, very painful install.

Where is this?  (city?  country?  continent?)

I still have the one from work from 1984 so I'm not in the market, but
people here do want to know.

-ethan