Re: HP-35/45 Simulator for PDP-8

[Keven Miller]

There is a nice HP-16C emulator for Windows - and Android.
http://www.wrpn.emmet-gray.com/

Also has Java version

(and sources)
Keven Miller



- Original Message - 
From: "Marc Howard" 
To: "General Discussion: On-Topic and Off-Topic Posts" 


Sent: Wed 07 Sep 2016 09:53 AM
Subject: Re: HP-35/45 Simulator for PDP-8



I'd vote for the HP-1xC line myself.  You can get 5 different calculators
(financial, 3 x scientific and programmer) for nearly the effort of the
first one.

The HP-16C (http://www.hpmuseum.org/hp16.htm) would be especially helpful
as it can easily be converted to calculate with a 12 bit with carry width
and octal operation with just a few keystrokes.  Even does 1's
complement/18 bits if you happen to have a PDP-1 lying around.

Re: HP-35/45 Simulator for PDP-8

[Keven Miller]

There is a nice HP-16C emulator for Windows - and Android.
 http://www.wrpn.emmet-gray.com/

Also has Java version

(and sources)
Keven Miller



- Original Message - 
From: "Marc Howard" 
To: "General Discussion: On-Topic and Off-Topic Posts" 


Sent: Wed 07 Sep 2016 09:53 AM
Subject: Re: HP-35/45 Simulator for PDP-8



I'd vote for the HP-1xC line myself.  You can get 5 different calculators
(financial, 3 x scientific and programmer) for nearly the effort of the
first one.

The HP-16C (http://www.hpmuseum.org/hp16.htm) would be especially helpful
as it can easily be converted to calculate with a 12 bit with carry width
and octal operation with just a few keystrokes.  Even does 1's
complement/18 bits if you happen to have a PDP-1 lying around.

Re: RK05 packs

[Ethan Dicks]

On Wed, Sep 7, 2016 at 1:18 PM, Noel Chiappa  wrote:
> Yeah, I think that was the original source of these packs. The Diablo 30/31
> drives (used on the RK11-C controller before the RK05 was created) were
> designed to use 2315 packs.

I have one RK11-C (as well as RK11-D, RKV11-D and RK8E) and I used to
have a Diablo 30, but it was badly damaged in a (backed-up sewer)
flood 25 years ago and discarded.  It's on the restoration list with
the other Unibus gear...

-ethan

Re: Odd memory error in PDP-11/04

[Ethan Dicks]

On Wed, Sep 7, 2016 at 1:46 PM, Noel Chiappa  wrote:
> > From: Paul Koning
>
> > A possible reason would be that the address drivers for that bit, or
> > the address decoders in that chip, are busted. The result would be that
> > reads and writes always touch the same address in the chip.
>
> Oooh, good point. That's a better explanation of the symptoms than mine,
> since it answers the thing that was confusing me ("why it can be either set
> or reset with a write, but freezes in one state for reads").

Hmm... I see how that would "work"... interesting.

> A fully-populated 64KB MS11-J card has 4 rows of 16Kx1 chips...

This is a 64KB M7847 DJ with 72 (4 rows of 18) Mostek MK4027 chips...

We did lose at least one of these back in the 80s.  I have 1-2 ones
needing inspection and repair.  Those are far, far down the pile to
investigate.  This particular board was working through the early 90s
before I stopped using it for testing COMBOARDs.

I also do have some 256KB boards,
> so if the
> machine ever runs again, the first thing to check is to see if that bit at
> 04 (or 010, if it's a larger than 32KB card) is tied to that bit at
> 0; if not, it's the addressing circuitry in the chip. (Looks like E75, but it
> might be E72).

Right.  I did some tests like that but I didn't capture the results
and I can't reproduce them yet.

> > From: Jim Stephens
>
> > Is there a hint as far as the affected hardware in that the ODT is
> > working, but the ram is not? The rom that is running ODT is also being
> > accessed for read correctly.
>
> Good point. So it's probably not something in the CPU that's repeating every
> 020 locations.

Good point.

> Also, IIRC, that ODT code doesn't use memory, it runs entirely out of the
> registers.

I think that's correct.

> Anyway, if the 020 problem is in the memory too, it's probably the A04 bus
> receiver (E55), although it might be the address latch (E88, a 7475) or the
> RAS/CAS mux (E99, 74S153). Step a would be to put a scope probe on the output
> of the bus receiver (pin 2) and see if it's hopping up and down - if that,
> that chip is OK, and the problem is further down the line.

Sure.  Makes sense.

> > I don't know if the rom path to the ODT code is different than the ram,
>
> Yes. The ROM for the ODT is stored in the M9301 card (at least, if it's an
> 11/04, it's probably an M9301 - could be an M9312, too).

M9312, as mentioned.  I have many of those.  So far, I'm still using
the one that was in this machine for 35 years, but I have many others,
and several common boot ROMs (DD, RX, RL...)

> The RAM is in another card, an M7847 (MS11-J).

Precisely.

> > it is interesting that the console code is being fetched, along with
> > the data from the serial controller to communicate with the console
> > terminal
>
> Which indicates that the UNIBUS is probably OK; the console serial is on yet
> another card, the M7856 (DL11-W); the CPU, RAM, bootstrap and serial line all
> talk to one another over the UNIBUS.

Yes.  That is "obvious" and I should have immediately realized that
the CPU and bus must be happy or I would have no ODT.  Must be the
RAM, or at least it was before the whole thing stopped responding.
Now, it's probably the RAM and the CPU.  I did swap back in my first
DL11-W and that does (still) stuff up SACK, so it has its own
problems.  I have one recently working and one recently non-working
DL11-W and one that came to me with some obvious mouse damage that
might be recoverable - it's in the corner by the 40-pin connector and
I think to really clean it, I'll have to remove that connector and
clean that entire quadrant, but, again, another problem for another
time.  Just getting ODT back will be a small win, then debugging the
RAM card will be another.

So far, the repair has been one 7474 on the console board.  Looks like
1-2 more chips will need to be replaced, at least.  I do have a few
parts of the era.

Thanks, all, who chimed in.  So far, the observations and advice have
been great!

-ethan

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Glen Slick]

On Wed, Sep 7, 2016 at 5:31 PM, Pete Turnbull  wrote:
> On 08/09/2016 00:37, Glen Slick wrote:
>
>> Basically this boils down to having the MXV11-B2 Boot ROMs installed
>> on either an MXV11-B or MRV11-D. The MXV11-B2 Boot ROMs are apparently
>> not compatible with the BDV11, for reasons I don't remember 100% off
>> the top of my head.
>
> Too big.  They're a pair of 8K ROMs, but the BDV11 only supports 2K and 1K
> devices.
>

I thought there was something else beyond that, maybe the ROM
windowing scheme was different or something like that.

If it is really nothing more than the size of the MXV11-B2 ROMs of
8Kx8 being too big, then maybe it would work by splitting the ROM
images across 2Kx8 EPROMs.

People have been successful putting the KDF11-BG ROM images on a BDV11
for use with an M8186 KDF11-A by splitting the two 8Kx8 images across
eight 2Kx8 2716 EPROMs.

http://www.vcfed.org/forum/showthread.php?24754-Qbus-Memory-cards/page2

I have been meaning to try that myself sometime.

Q-Bus Memory Diagnostics and Repair

[Jerry Weiss]

I have two bad memory boards and could use some advise on how to
repair them. 

The first is an MSV11-PL 512KB-Q-Bus 22bit. 
Dead to both CSR and Memory address access in ODT.  
Was working until a short time ago. Checked all the jumpers and 
no evidence any magic smoke has been released. I have a copy of 
MP01239_MSV11-P Field Maintenance Print, but before start poking 
around with my scope I wonder if someone has seen this before 
and/or can recommend a particular methodology to finding the fault.

The second board is a CMV1000 that probably has a bad Memory Chip.  
The results of CVMJAB0 point to “Bank 35”.   I don’t have either 
prints or a manual for this board.  Partial report follows: 

   512K OF Q-BUS PARITY MEMORY
   512K WORDS OF MEMORY TOTAL

MEMORY CONFIGURATION MAP
 16K WORD BANKS
1   2   3   4   5   6   7
012345670123456701234567012345670123456701234567012345670123
ERRORS   X
MEMTYPE 
CSR 

  PCBANK  VADD PADD GOOD BAD XOR  CSR  MTYP INT PAT
025770   35  157752  03577752  000377  03577752  03577752  0 P   17
025770   35  157712  03577712  000377  03577712  03577712  0 P   17
025770   35  157652  03577652  000377  03577652  03577652  0 P   17
025770   35  157612  03577612  000377  03577612  03577612  0 P   17
025770   35  157552  03577552  000377  03577552  03577552  0 P   17

024564   35  141612  03561612  061612  03561612  03561612  0 P   01
024564   35  141652  03561652  061652  03561652  03561652  0 P   01
024564   35  142712  03562712  062712  03562712  03562712  0 P   01
024564   35  143712  03563712  063712  03563712  03563712  0 P   01
024564   35  143752  03563752  063752  063752  00  0 P   01
024564   35  145552  03565552  065552  03565552  03565552  0 P   01
024564   35  145652  03565652  065652  065652  00  0 P   01

024622   35  141412  03561412  116365  03561412  03561412  0 P   02
024622   35  141452  03561452  116325  03561452  03561452  0 P   02
024622   35  141512  03561512  116265  03561512  03561512  0 P   02
024622   35  141552  03561552  116225  03561552  03561552  0 P   02

I was expecting bad and xor to be 16bit  values, but they appear to be
mostly 22bit addresses. But then again this isn’t a DEC board.

The board itself is labeled with bits 0-7 P0 P1 8-15 across the top and
8 rows of chips (MT4264-15).  Any suggestions as to which chip might be
suspect?

Jerry

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Pete Turnbull]

On 08/09/2016 00:37, Glen Slick wrote:


Basically this boils down to having the MXV11-B2 Boot ROMs installed
on either an MXV11-B or MRV11-D. The MXV11-B2 Boot ROMs are apparently
not compatible with the BDV11, for reasons I don't remember 100% off
the top of my head.


Too big.  They're a pair of 8K ROMs, but the BDV11 only supports 2K and 
1K devices.



Why are MRV11-D boards so expensive, at least on eBay? Were they sold
in relatively low volume compared to CPU boards?


I guess that's the reason.  I've only ever seen two, but I've seen (in 
fact I have) lots more earlier ROM boards and several MXV11-Bs.  I 
suppose by the time the MRV11-D came out, people who needed a bootstrap 
paging capability either had 11/03 or 11/23 systems with BDV11s or, if 
they needed an 8K bootstrap, had microPDP-11s, in which the bootstrap is 
always on the CPU card.  Almost anything else could use the cheaper 
MRV11-C (though it only supports up to 4K chips) and even that supports 
the conventional bootstrap mechanism, albeit only 16- or 18-bit, not 
using BBS7.


--
Pete
Pete Turnbull

National MM57409 "Super Number Cruncher", MM57109 "Number Oriented Processor"

[Eric Smith]

I finally got my hands on a couple of MM57409 "Super Number Cruncher"
chips with 1985 date codes. I think it was probably introduced around
1982. It's a NMOS part with the same concept (though not compatible
with) the earlier PMOS MM57109 "Number Oriented Processor", which was
introduced in 1977.

In both cases, National took their existing 4-bit masked-ROM
microcontroller designs (MM5799 PMOS, COP440 NMOS), and the floating
point code they'd already written for calculator chips, and turned
them into math coprocessors. The MM57109 also had some support for
acting as a floating point general purpose processor.

The COP4xx has a test mode, so I should be able to dump the ROM of the
MM57409. The MM5799 almost certainly had a test mode as well, but I
haven't uncovered any documentation for it, so the ROM might have to
be dumped optically.

The MM57109 uses an 8-digit mantissa, and a divide takes an average of
78ms, and worst-case 223ms.  The MM57409 has a 12-digit mantissa, and
worst-case dvidie time is 66ms, with no average stated.  Both also
have a reasonably full complement of functions that would be found on
a typical scientific calculator, including transcendentals.

Both are quite slow compared to contemporary math coprocessors such as
the AMD Am9511A (second-source by Intel as the 8231A), and insanely
slow compared to the 8087.

I'm tempted to wire up one of these (either kind) to an Apple II, and
hack Applesoft to use it as a floating point decelerator. Back in the
day, a few companies sold Am9511A cards for the Apple II.  Of course,
since Applesoft uses binary floating point but these National
Semiconductor chips use BCD, the necessary conversion code running on
the 6502 would make it even slower. Perhaps Atari BASIC would be a
better choice as it used BCD.

Re: HP-35/45 Simulator for PDP-8

[Eric Smith]

On Wed, Sep 7, 2016 at 9:15 AM, Kyle Owen  wrote:
> I could imagine OS/8 would come in handy here, as we could swap fields out,
> maybe between several fields of ROM instructions, as kind of a cache
> approach. There would be a ROM file that's required for use.

I thought about swapping, but the microcode jumps around so much that
it would be insanely slow.

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Glen Slick]

On Wed, Sep 7, 2016 at 3:59 PM, Pete Turnbull  wrote:
>
> Yes, it has a lot of ROM sockets: it's a bootstrap/terminator/LTC card. In
> fact it's the archetypal bootstrap card, the one that first had the paging
> mechanisms all the others use.  The problem is none of the sockets support
> large ROMs, so there's a lot of fiddling to do to get a microPDP-11
> bootstrap and diagnostics in there.  You have to split each ROM into four
> devices, so eight in total.  I'm well aware of how BBS7 works, but that's
> not the issue.  Unless the BDV11 is modified, it doesn't work correctly in a
> 22-bit system as it has 18-bit termination. Although DEC listed the BDV11
> (Rev.F only) as compatible they classed 22-bit 11/73 systems using a BDV11
> of any sort as "not field serviceable" and wouldn't supply or support any
> that way.
>

http://www.bitsavers.org/pdf/dec/qbus/oemMicronotes.pdf
uNOTE #004
LSI-11/73 Upgrade Paths

"NOTE
1. In the following upgrade scenarios, the systems have been labeled
as being Field Serviceable or not. A system which is Field Serviceable
has a bootstrap which meets Field Service requirements. The
requirement is that the bootstrap must execute an 11/73 cache memory
diagnostic on power-up. There is not guarantee that the overall system
will be Field Serviceable or that it will be FCC compliant."

Basically this boils down to having the MXV11-B2 Boot ROMs installed
on either an MXV11-B or MRV11-D. The MXV11-B2 Boot ROMs are apparently
not compatible with the BDV11, for reasons I don't remember 100% off
the top of my head.

Why are MRV11-D boards so expensive, at least on eBay? Were they sold
in relatively low volume compared to CPU boards?

Re: Y Combinator is restoring one of Alan Kay's Xerox Alto machines

[Josh Dersch]

On Wed, Sep 7, 2016 at 3:43 PM, CuriousMarc  wrote:

> > > On Sep 5, 2016, at 9:30 AM, Josh Dersch  wrote:
> > >
> > > At the LCM, I used an Apple II to test out the Alto's memory -- the
> > > Alto II XM uses 4116 RAM chips.  I swapped in a row at a time and wrote
> a
> > > little BASIC program to test for obvious errors.  This was
> > > time-consuming, but eliminated the obviously bad chips, which helped
> immensely.
> >
> > Oh, that's so simple and clever! Are these 16k chips? I don't have an
> Apple II,
> > but I wonder if I could use the same trick and plug them in my HP 85
> > for which I just managed to burn the service ROM, which has a memory
> > test built in.
>
> Josh,
> I checked, and the mysterious HP 1818-1396 or 1818-0341 RAM chips used in
> the HP-85 appear to be NEC uPD416-2 or MOSTEK 16k chips. They appear to be
> pin for pin, voltage and speed compatible with the MOSTEK 4116-3 used in
> the
> Alto. So it looks like I could check the Alto Xerox II-XM RAM chips on my
> HP-85.
> 8 at a time, that might take a while :-). Thanks for the tip, I'd never
> have
> thought about it!
> Marc
>
>
Yep, the NEC uPD416D's are what we have in the Alto we recently restored.
And yeah, it takes awhile, but it's worth the effort :).

Have fun!
- Josh

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Pete Turnbull]

On 07/09/2016 22:35, Noel Chiappa wrote:

> From: Pete Turnbull
> Don't forget the LTC :-)

?? The KDJ11-A has an on-board LTC - see EK-KDJ1A-UG-001, pg. 1-7.


So it does.  I'd forgotten that!


> Otherwise, you'd need an additional bootstrap card such as an MRV11-D
> with -B2 boot ROMs, a DLVE1 (DLV11-JE) for the SLUs, something with an
> LTC, and termination.

Err, the KDJ11-A has on-board termination: see MP-01890 pg. 1 of 9, on the LHS.


I meant for the other end of the bus.


> A BDV11 wouldn't work as it doesn't have the ROM capability

?? The BDV11 is a ROM board?

(And it works fine in a Q22 bus; the address recognition circuitry uses BBS7,
it doesn't look at BDAL 16 and above.)


Yes, it has a lot of ROM sockets: it's a bootstrap/terminator/LTC card. 
In fact it's the archetypal bootstrap card, the one that first had the 
paging mechanisms all the others use.  The problem is none of the 
sockets support large ROMs, so there's a lot of fiddling to do to get a 
microPDP-11 bootstrap and diagnostics in there.  You have to split each 
ROM into four devices, so eight in total.  I'm well aware of how BBS7 
works, but that's not the issue.  Unless the BDV11 is modified, it 
doesn't work correctly in a 22-bit system as it has 18-bit termination. 
Although DEC listed the BDV11 (Rev.F only) as compatible they classed 
22-bit 11/73 systems using a BDV11 of any sort as "not field 
serviceable" and wouldn't supply or support any that way.


--
Pete
Pete Turnbull

RE: Y Combinator is restoring one of Alan Kay's Xerox Alto machines

[CuriousMarc]

> > On Sep 5, 2016, at 9:30 AM, Josh Dersch  wrote:
> >
> > At the LCM, I used an Apple II to test out the Alto's memory -- the 
> > Alto II XM uses 4116 RAM chips.  I swapped in a row at a time and wrote
a 
> > little BASIC program to test for obvious errors.  This was 
> > time-consuming, but eliminated the obviously bad chips, which helped
immensely.
> 
> Oh, that's so simple and clever! Are these 16k chips? I don't have an
Apple II,
> but I wonder if I could use the same trick and plug them in my HP 85 
> for which I just managed to burn the service ROM, which has a memory 
> test built in.

Josh,
I checked, and the mysterious HP 1818-1396 or 1818-0341 RAM chips used in
the HP-85 appear to be NEC uPD416-2 or MOSTEK 16k chips. They appear to be
pin for pin, voltage and speed compatible with the MOSTEK 4116-3 used in the
Alto. So it looks like I could check the Alto Xerox II-XM RAM chips on my
HP-85. 
8 at a time, that might take a while :-). Thanks for the tip, I'd never have
thought about it!
Marc

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Noel Chiappa]

> From: Pete Turnbull

>> The other thing that makes no sense is that the KDJ11-B (M8190) has
>> all that extra circuitry on it to support PMI, etc - all of which is
>> unused in the 11/73 application! Why not just plug in a (presumably
>> cheaper) M8192? In the /73 application, the two are basically equivalent.

> Don't forget the LTC :-)

?? The KDJ11-A has an on-board LTC - see EK-KDJ1A-UG-001, pg. 1-7.

> Otherwise, you'd need an additional bootstrap card such as an MRV11-D
> with -B2 boot ROMs, a DLVE1 (DLV11-JE) for the SLUs, something with an
> LTC, and termination.

Err, the KDJ11-A has on-board termination: see MP-01890 pg. 1 of 9, on the LHS.

> A BDV11 wouldn't work as it doesn't have the ROM capability 

?? The BDV11 is a ROM board?

(And it works fine in a Q22 bus; the address recognition circuitry uses BBS7,
it doesn't look at BDAL 16 and above.)

Noel

Re: VC8E Option

[Kyle Owen]

On Wed, Sep 7, 2016 at 4:20 PM, Vincent Slyngstad 
wrote:

>
> That driver contains the line:
>JMS I (STRTHL+4 /CALL PROGRAM HELP
>
> which calls the code in
> http://bitsavers.trailing-edge.com/bits/DEC/pdp8/papertapeIm
> ages/russ.ucs.indiana.edu/Utils/VC8E/Ascii/help.pa
>
> which is what I think you were looking for.
>

Thanks Vince! Yes, that's definitely it. I've been staring at the somewhat
related Tektronix 4013 terminal emulator too, in a couple of parent
directories above. I need to do some more investigating to figure out how
the driver actually works, but it looks like both programs are very
dependent on the store mode of the oscilloscope. Based on what I see, there
is no massive buffer that the driver iterates through to keep things
refreshed, but I might be missing it.

Now I'm working on real VC8E integration into SimH to better tell how these
programs work. Anyone want to help? :)

Kyle

Re: VC8E Option

[Vincent Slyngstad]

From: Kyle Owen: Wednesday, September 07, 2016 9:04 AM


However, unless I'm missing something, I don't actually see what would've
drawn the characters. A little digging on Bitsavers shows there was a VC8E
driver.

http://bitsavers.trailing-edge.com/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu/Utils/VC8E/Ascii/havc8e.pa

Even in this, I don't see any sign of a character lookup table or the like.
Where would all of this have been created?


That driver contains the line:
   JMS I (STRTHL+4 /CALL PROGRAM HELP

which calls the code in
http://bitsavers.trailing-edge.com/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu/Utils/VC8E/Ascii/help.pa

which is what I think you were looking for.

   Vince

Re: RK05 packs

[Al Kossow]

On 9/7/16 11:46 AM, Paul Koning wrote:

> TPI, as in "transitions per inch"?
> 

tracks per inch

> I vaguely remember that the 1311 (20 sectors of 200 digits each per track) 
> used silvery colored heads.  I wonder if those are the same.  They were 
> pretty sturdy; one day when we had a hydraulic leak, the FE just cleaned 
> heads and pack with isopropyl alcohol, fixed the leak, and put the drive and 
> pack back into service.
> 

2311 is 100 tpi, 2314 is 200


http://s3.computerhistory.org/groups/ibm-1311-2311.pdf has a nice picture of 
the 2311 heads

Re: MicroPDP-11/73, was Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Pete Turnbull]

On 07/09/2016 20:20, Steven M Jones wrote:

Anybody know what the most common actually-shipped configuration of the
MicroPDP-11/73 were? BA23, M8190, 1 RAM board, RQDX_, and DLV11?


From my experience servicing them in the UK, pretty much that.  I saw a 
few with DEQNAs and some with two memory boards, though.  But it would 
be interesting to see a sales person's perspective.  I have a feeling a 
significant number were bought as one config and later expanded, 
especially as memory got less expensive.  Expansion or addition was 
certainly true for storage.


--
Pete
Pete Turnbull

Re: HP-35/45 Simulator for PDP-8

[Marc Howard]

I'd vote for the HP-1xC line myself.  You can get 5 different calculators
(financial, 3 x scientific and programmer) for nearly the effort of the
first one.

The HP-16C (http://www.hpmuseum.org/hp16.htm) would be especially helpful
as it can easily be converted to calculate with a 12 bit with carry width
and octal operation with just a few keystrokes.  Even does 1's
complement/18 bits if you happen to have a PDP-1 lying around.

On Tue, Sep 6, 2016 at 11:10 PM, Kyle Owen  wrote:

> I updated the project to include optional OS/8 support. I won't say I've
> tested it extensively, but it does seem to be working as expected in SimH,
> anyways. I updated the README to reflect the additions. The directory
> structure was also updated to something more sane.
>
> The keen observer will note that I also changed up some of the debugging
> features which are likely to not be useful to anyone other than the
> author...and even then, I only used the features a few times when getting
> the thing running initially. But, it's there if you need it, all
> configurable through the switch register as detailed in the source.
>
> Glad some folks got a kick out of it enough to try it out! Feel free to
> suggest improvements where you see fit. I was thinking about adding support
> to read keystrokes from a file for macro programmability...but that might
> be too absurd even for this project. Maybe the HP-41C simulator is next...
> :)
>
> Kyle
>

Re: PDP-8 core memory problems.

[Doug Ingraham]

The most likely cause of what you are seeing is a broken wire when the
plane was originally assembled.  The wire was pulled back a few cores and
the end stripped.  New wire was soldered to old, insulated and then they
continued threading in that wire.  Over the years the solder joint has
degraded or the wire broke at the stress riser found at one end of the
solder joint and now you have an open circuit. I've not heard of this kind
of problem on the Straight 8 but that may be due to the rarity of the
processors.  It is apparently a fairly common failure on the 8I core planes.

As was stated you have nothing to lose in attempting a repair as the core
is useless as is.  A steady hand, good desoldering tools, lots of photos
and you should be able to take it apart, effect the repair and
re-assemble.  Keep in mind that the core beads themselves are extremely
fragile so take precautions that nothing gets dropped on it.  Broken core
beads are pretty much a death sentence to the memory.  Replacements are
unobtanium and if you decided to make the beads you would have trouble
matching the originals well enough to tune the core to work with both new
and old.  You would end up making a whole new core assembly consisting of
49152 beads.  You would need to be really determined to attempt that.

I did come up with an idea that is simply too dangerous to try.  Connect a
power supply to the ends of the wire and ramp up the voltage until it just
starts to conduct.  This could be several hundred to several thousand
volts.  As soon as it starts to conduct the broken ends of the wire will
start to heat and the moment the current starts to shoot up (the resistance
drops) you need to cut power.  You will have welded the broken ends of the
wire together.  The problem is that if anything goes wrong you are in worse
shape than now and you really only get once shot at it.  And the assumption
is that the broken ends are in close proximity.

Here is wishing you a steady hand and lots of luck!

-- 
Doug Ingraham
PDP-8 SN 1175

ENIAC Simulator

[Brian L. Stuart]

Unfortunately, I won't be able to make it to VCFMW this year.
(Those of you who don't know me are probably thinking "So what?"
Those who do are probably split between "Aww, that's too bad"
and "Good; he's a pain in the...")  In lieu of my "sparkling
personality" I'm making available the ENIAC simulator I would
have exhibited had I committed to coming early enough to reserve
a table.

If you attended VCFSE or VCFE this year, you may have seen an
early version of the simulator.  It's now at a beta testable
level of operation.  The files you'll want to download and some
minimal instructions for use are at:

http://cs.drexel.edu/~bls96/eniac/eniac.html

It's written in Go, so you should be able to compile it on a
variety of platforms.  For those not wanting to compile it themselves,
I've included binaries for several options including Linux/amd64,
Linux/arm, FreeBSD/amd64, FreeBSD/i386, MacOS/amd64, and Win/amd64.
The Windows version has not been tested at all, and only minimal
testing has been done on the Mac version.  You'll also need TCL/Tk
installed to get the wish program available as used by the GUI.

Suggestions, comments, criticisms, and questions are welcome, but
it will probably be a few weeks before I'll be able to make time to
do anything about them.

Enjoy.
BLS

Re: MicroPDP-11/73, was Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Paul Koning]

> On Sep 7, 2016, at 3:20 PM, Steven M Jones  wrote:
> 
> On 09/07/16 05:02, Noel Chiappa wrote:
>> 
>> The other thing that makes no sense is that the KDJ11-B (M8190) has all that
>> extra circuitry on it to support PMI, etc - all of which is unused in the
>> 11/73 application! Why not just plug in a (presumably cheaper) M8192?
> 
> In Marketing-land, the VAXstation II RC, with epoxy in the
> factory-unused slots, makes sense...

Not just marketing.  Reusing an existing module that does more than is needed 
may well be the most economical option.  You balance higher per-unit cost 
against much lower engineering investment.  If you build a million widgets, 
that's probably the wrong way to go; but if it's only a few thousand it may 
make perfectly good sense.

paul

MicroPDP-11/73, was Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Steven M Jones]

On 09/07/16 05:02, Noel Chiappa wrote:
> 
> The other thing that makes no sense is that the KDJ11-B (M8190) has all that
> extra circuitry on it to support PMI, etc - all of which is unused in the
> 11/73 application! Why not just plug in a (presumably cheaper) M8192?

In Marketing-land, the VAXstation II RC, with epoxy in the
factory-unused slots, makes sense...


On 09/07/16 07:34, Pete Turnbull wrote:
>  
> Don't forget the LTC :-)  All in all it saves a decent amount of
> backplane space, makes field service easier, and follows DEC's attempts
> to integrate as much as possible.  Otherwise, you'd need an additional
> bootstrap card such as an MRV11-D with -B2 boot ROMs, a DLVE1 (DLV11-JE)
> for the SLUs, something with an LTC, and termination.  That's at least
> twice as many slots in a Q-Q backplane and four slots in Q-CD.

I think this makes sense in Engineering-land, good point. ;)

Anybody know what the most common actually-shipped configuration of the
MicroPDP-11/73 were? BA23, M8190, 1 RAM board, RQDX_, and DLV11?

--S.

Re: RK05 packs

[Paul Koning]

> On Sep 7, 2016, at 2:45 PM, Al Kossow  wrote:
> 
> 
> 
> On 9/7/16 11:21 AM, Paul Koning wrote:
> 
>> That would fit the IBM 2315 if indeed it used one sector notch for each 
>> sector (it has 8 per track).
>> 
> 
> and 100 TPI
> 
> Original Diablo drives were also 100 TPI, and used silver colored heads, 
> moving to 200 TPI and the more
> common white ceramic heads.
> 
> Apparently, the 100 TPI Diablo heads are extremely difficult to find today. I 
> remember all the 100 TPI
> Diablo drives at a friend's company getting converted to 200.

TPI, as in "transitions per inch"?

I vaguely remember that the 1311 (20 sectors of 200 digits each per track) used 
silvery colored heads.  I wonder if those are the same.  They were pretty 
sturdy; one day when we had a hydraulic leak, the FE just cleaned heads and 
pack with isopropyl alcohol, fixed the leak, and put the drive and pack back 
into service.

paul

Re: RK05 packs

[Al Kossow]

On 9/7/16 11:21 AM, Paul Koning wrote:

> That would fit the IBM 2315 if indeed it used one sector notch for each 
> sector (it has 8 per track).
>

and 100 TPI

Original Diablo drives were also 100 TPI, and used silver colored heads, moving 
to 200 TPI and the more
common white ceramic heads.

Apparently, the 100 TPI Diablo heads are extremely difficult to find today. I 
remember all the 100 TPI
Diablo drives at a friend's company getting converted to 200.

Re: RK05 packs

[Paul Koning]

> On Sep 7, 2016, at 1:51 PM, tony duell  wrote:
> ...
> Didn't the DEC RK01 use 8 sector packs? Something certainly did. 

That would fit the IBM 2315 if indeed it used one sector notch for each sector 
(it has 8 per track).

paul

RE: RK05 packs

[tony duell]

> FWIW Burroughs also used drives/platters like this with their small systems
> (B80 - B1800); ISTR that they were ~ 5MB but 32 SPT instead of  12 or 16; 
> unfortunately I dumped all of mine long ago.

I can remember when the Inmac catalogue (that dates me...) told you 
to count the number of notches in the hub, subtract 1 (for the index
notch) and order the appropriate pack. I can't remember which ones
were listed. 

Didn't the DEC RK01 use 8 sector packs? Something certainly did. 

-tony

Re: RK05 packs

[Mike Stein]

- Original Message - 
From: "Noel Chiappa" 
To: 
Cc: 
Sent: Wednesday, September 07, 2016 1:18 PM
Subject: Re: RK05 packs


>From: Paul Koning
> 
>> Some IBM systems ... have a "2315" drive which is an RK05. 
> 
> Yeah, I think that was the original source of these packs. The Diablo 30/31
> drives (used on the RK11-C controller before the RK05 was created) were
> designed to use 2315 packs.
> 
>> From: Tony Duell
> 
>> My intention was to put the hub on a spare spindle .. put the platter
>> on, turn it round by hand and use a lever-type dial gauge to get
>> minimum run-out. 
> 
> One of the people I buy PDP-11 parts from reports that he actually did this
> (using the exact procedure you describe) BITD. Apparently there's some
> multi-platter pack that has the same exact platter as the RK05 (2315) pack,
> and he had some damaged RK05 packs, and moved platters from the bad
> multi-platter pack to the RK05's.
> 
> Noel


FWIW Burroughs also used drives/platters like this with their small systems 
(B80 - B1800); ISTR that they were ~ 5MB but 32 SPT instead of  12 or 16; 
unfortunately I dumped all of mine long ago.

http://www.ricomputermuseum.org/Home/equipment/burroughs-b800

m

RE: RK05 packs

[tony duell]

> > I looked into this a couple of years ago with the intention of making
> > a 24 sector pack for an HP7900 (actually part of an HP9880). Starting
> > from a 12 sector pack of course.
> >
> > This project got interupted by a house move and I've not gone back
> > to it yet, but I did discover there is no alignment ridge or anything
> > between the hub and platter. The platter fits on the flat top of the
> > hub, there is a clamping ring that is then screwed down to anchor
> > it.
> 
> Did you construct an engineering drawing of the hub based on your 
> observations?

No. There is no need for what I want to do. I just need to put an extra
notch between each of the sectoring notches, I think (I will have to 
investigate what happens with the index notch, the one at the odd
spacing). It was my intention to put the hub on a dividing head, carefully
get one of the existing notches over a slitting saw, then rotate and
cut the next notch, etc.

> > My intention was to put the hub on a spare spindle (I happen to
> > have a load of RK05 drive spares), put the platter on, turn it round
> > by hand and use a lever-type dial gauge to get minimum run-out.
> 
> That's like the procedure for centering a work piece in a 4-jaw chuck. 

Sure, done that often enough.

> With care and patience you can get it centered to .001 inches (25 um),

And as you said the only real requirment is to get it balanced to avoid
vibration. I think a 1 thou runout would be good enough for that. Of
course the disk would have to be formatted after this modification
but that's not a problem.

In fact for my application (the HP9880) it may not be necessary. After 
battling through manuals and microcode, I have realised that the
thing actually treats it as a _12_ sector pack, starting a read or
write on alternate notches only. That means an electronic modification
(easier for me) would let you use normal 12 sector packs that I
have over a hundred of

-tony

Re: Odd memory error in PDP-11/04

[Noel Chiappa]

> From: Paul Koning

> Semiconductor memory, right?

Yup.

> A possible reason would be that the address drivers for that bit, or
> the address decoders in that chip, are busted. The result would be that
> reads and writes always touch the same address in the chip.

Oooh, good point. That's a better explanation of the symptoms than mine,
since it answers the thing that was confusing me ("why it can be either set
or reset with a write, but freezes in one state for reads").

A fully-populated 64KB MS11-J card has 4 rows of 16Kx1 chips, so if the
machine ever runs again, the first thing to check is to see if that bit at
04 (or 010, if it's a larger than 32KB card) is tied to that bit at
0; if not, it's the addressing circuitry in the chip. (Looks like E75, but it
might be E72).

> The fact that other bits repeat every 20 also suggests issues with
> addressing logic.

That I don't think is a memory chip issue, since it causes the entire word to
repeat, and on that card, each bit of the word is in a separate chip.


> From: Jim Stephens

> Is there a hint as far as the affected hardware in that the ODT is
> working, but the ram is not? The rom that is running ODT is also being
> accessed for read correctly. 

Good point. So it's probably not something in the CPU that's repeating every
020 locations.

Also, IIRC, that ODT code doesn't use memory, it runs entirely out of the
registers. There's some good reason for that (probably to avoid messing with
the contents of memory), but maybe also so that it runs without working
memory - ISTR that we discussed this at one point here, but I'm too lazy to
look for the discussion. So that's why ODT runs even if the RAM isn't working.

Anyway, if the 020 problem is in the memory too, it's probably the A04 bus
receiver (E55), although it might be the address latch (E88, a 7475) or the
RAS/CAS mux (E99, 74S153). Step a would be to put a scope probe on the output
of the bus receiver (pin 2) and see if it's hopping up and down - if that,
that chip is OK, and the problem is further down the line.

> I don't know if the rom path to the ODT code is different than the ram,

Yes. The ROM for the ODT is stored in the M9301 card (at least, if it's an
11/04, it's probably an M9301 - could be an M9312, too). The RAM is in
another card, an M7847 (MS11-J).

> it is interesting that the console code is being fetched, along with
> the data from the serial controller to communicate with the console
> terminal

Which indicates that the UNIBUS is probably OK; the console serial is on yet
another card, the M7856 (DL11-W); the CPU, RAM, bootstrap and serial line all
talk to one another over the UNIBUS.

Noel

Re: RK05 packs

[Noel Chiappa]

From: Paul Koning

> Some IBM systems ... have a "2315" drive which is an RK05. 

Yeah, I think that was the original source of these packs. The Diablo 30/31
drives (used on the RK11-C controller before the RK05 was created) were
designed to use 2315 packs.

> From: Tony Duell

> My intention was to put the hub on a spare spindle .. put the platter
> on, turn it round by hand and use a lever-type dial gauge to get
> minimum run-out. 

One of the people I buy PDP-11 parts from reports that he actually did this
(using the exact procedure you describe) BITD. Apparently there's some
multi-platter pack that has the same exact platter as the RK05 (2315) pack,
and he had some damaged RK05 packs, and moved platters from the bad
multi-platter pack to the RK05's.

Noel

Re: VC8E Option

[Charles Anthony]

On Wed, Sep 7, 2016 at 9:04 AM, Kyle Owen  wrote:

> Charles Dickman's site shows a VC8E screenshot with text:
>
> http://www.chdickman.com/pdp8/spacewar/
>
> However, unless I'm missing something, I don't actually see what would've
> drawn the characters. A little digging on Bitsavers shows there was a VC8E
> driver.
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp8/papertapeImages/russ.ucs.
> indiana.edu/Utils/VC8E/Ascii/havc8e.pa
>
> Even in this, I don't see any sign of a character lookup table or the like.
> Where would all of this have been created?
>
>
I have a vague memory of a FOCAL overlay for VC8/E that had a character
table in it, but I can't find it on the webs at the moment.

-- Charles

Re: Odd memory error in PDP-11/04

[jim stephens]

Is there a hint as far as the affected hardware in that the ODT is 
working, but the ram is not?  The rom that is running ODT is also being 
accessed for read correctly.  Perhaps the problem is migrating since the 
system halts however.  A wild jump and a fault if the rom path is 
affected might explain that.


I don't know if the rom path to the ODT code is different than the ram, 
you guys would know better, but it is interesting that the console code 
is being fetched, along with the data from the serial controller to 
communicate with the console terminal, but the ram behaves so odd.


Insight as to how this is arranged would be good to have both for this 
system and others.


thanks
Jim

On 9/7/2016 8:44 AM, Noel Chiappa wrote:

Yeah, sounds like the CPU is halting.

Re: RK05 packs

[Paul Koning]

> On Sep 7, 2016, at 11:56 AM, tony duell  wrote:
> 
> 
>> The other question is the disassembly of the pack and the installation 
>> of the new hub.  How is that done?  What are the concentricity
>> requirements for the platter?  Is there a mating surface (exterior cylinder
>> surface on the hub) or are platter and hub aligned in some fixture and
>> then clamped to hold the platter in position?  Clearly the pack would be
>> reformatted, so a small amount of runout would be ok, but it would have
>> to be small enough that the vibration is controlled.
> 
> I looked into this a couple of years ago with the intention of making
> a 24 sector pack for an HP7900 (actually part of an HP9880). Starting
> from a 12 sector pack of course.
> 
> This project got interupted by a house move and I've not gone back
> to it yet, but I did discover there is no alignment ridge or anything
> between the hub and platter. The platter fits on the flat top of the 
> hub, there is a clamping ring that is then screwed down to anchor
> it. 

Did you construct an engineering drawing of the hub based on your observations?

> My intention was to put the hub on a spare spindle (I happen to 
> have a load of RK05 drive spares), put the platter on, turn it round
> by hand and use a lever-type dial gauge to get minimum run-out. 

That's like the procedure for centering a work piece in a 4-jaw chuck.  With 
care and patience you can get it centered to .001 inches (25 um), give or take. 
 Another option would be to make a centering jig, one that holds the hub and 
platter.  If the outer diameter of the platter is held to tight tolerances that 
would work well; if that dimension is not tightly controlled then centering 
with an indicator gauge will work better.

With a spare spindle like that, you'd also be able to verify the balance 
afterwards, by spinning up the finished platter and checking the vibration 
level.

paul

Re: Odd memory error in PDP-11/04

[Paul Koning]

> On Sep 7, 2016, at 11:44 AM, Noel Chiappa  wrote:
> 
>> From: Ethan Dicks
> 
> Let's look at this one first, this is probably the easier to solve.
> 
 2) Setting D10 in location 00 results in D10 set in all the
 locations
> 
>>> Sorry, didn't follow that? Did you mean that if you store 02000 in
>>> location 0, all other locations now report the 02000 bit set?
> 
>> Only 04000, but, yes.
> 
> Ah. That's D11. :-)
> 
>> If I set that bit in location 0, or other locations, it gets set in all
>> locations. If I clear that bit, it clears.
> 
> So that's likely in the memory (although I suppose it could be the CPU,
> _somehow_). It sounds like there's a latch somewhere in the output path
> (because it affects all locations right away, not just once you've written to
> them) that's getting set one way or the other, and and then, won't change. I
> suspect the problem is with the flop for that bit, not in the circuitry
> that's clearing/clocking that flop, since it only affects that one bit.

Semiconductor memory, right?  A possible reason would be that the address 
drivers for that bit, or the address decoders in that chip, are busted.  The 
result would be that reads and writes always touch the same address in the chip.

The fact that other bits repeat every 20 also suggests issues with addressing 
logic.  I'd suggest checking the address signals on the memory card.

paul

DEC professionals Power Supply ...

[emanuel stiebler]

Anybody has a spare one, to sell?

With all the discussions about the P350/P380, I went to my storage,
and found two p350s without power supplies :(

Cheers

Re: RK05 packs

[Paul Koning]

> On Sep 7, 2016, at 8:51 AM, Noel Chiappa  wrote:
> 
>> From: Ethan Dicks
> 
>> 12-sector packs are abundant compared to 16-sector packs
> 
> Really? Most of the RK05 packs I've seen for sale on eBay in the last couple
> of years have been 16-sector - so I naturally assumed they were more common.

Interesting.  They are best known as PDP-8 packs, but there's another use for 
them and I wonder if that is relevant.  Some IBM systems -- the 360 model 44 
for example -- have a "2315" drive which is an RK05.  And I vaguely remember 
seeing 16 sector slots in that pack the one time I pulled it out of our college 
360/44.  The IBM manual speaks of 8 sectors per track, 366 bytes per sector.  
Weird.  But 200 cylinders plus 3 spare, just as for the RK05s we know.

paul

VC8E Option

[Kyle Owen]

Charles Dickman's site shows a VC8E screenshot with text:

http://www.chdickman.com/pdp8/spacewar/

However, unless I'm missing something, I don't actually see what would've
drawn the characters. A little digging on Bitsavers shows there was a VC8E
driver.

http://bitsavers.trailing-edge.com/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu/Utils/VC8E/Ascii/havc8e.pa

Even in this, I don't see any sign of a character lookup table or the like.
Where would all of this have been created?

Thanks,

Kyle

Re: SWTPC 6800 weirdness

[Chris Elmquist]

On Wednesday (09/07/2016 at 08:04AM -0700), Brad H wrote:
> 
> Thanks Chris.  I figured it was something like that with my first MP-M.  I am 
> curious though why simply setting another board to cover 8000-BFFF won't 
> allow the system to operate in that board's absence.  It bothers me that I'm 
> reliant on that heavily modded unit to be able to operate.

Unless your MP-B (and MP-A) have been additionally modified to move the
I/O region away from $8000, then your problem is that you are addressing
RAM on top of the I/O region from $8000 to $8FFF.

You need RAM at,

$A000 to $A07F (128 bytes) or $A000-$AFFF (4K bytes)

$ to $7FFF (as much as you have, no more than 32K)

You can't have RAM at,

$8000 to $8FFF   this is the I/O region

The monitor ROM occupies,

$E000 to $

There might be add-on PROMs on floppy controllers in the range,

$C000 to $CFFF

There might be floppy or other special I/O in the range,

$D000 to $DFFF

The $8000 I/O range is decoded on the motherboard and the original
systems took the entire 4K block from $8000 to $8FFF.  You cannot also
put RAM there because it collides with the I/O devices such as the MP-C,
MP-S and anything else on the SS-30 bus.

There were modifications later that moved the I/O elsewhere but if that
is done, then lots of the software (and firmware) needs to change too
and most certainly the stock MIKBUG or SWTBUG will not work with I/O
somewhere other than $8000.

So, I think another problem you are facing is that when you put in some
of these other memory boards, they are getting double addressed with other
memory boards or with I/O and that will certainly cause bad behavior.

> I have another general question for folks out there.  I'm trying to 
> understand exactly how memory addressing works in relation to these boards.  
> For example, if I understand correctly, the original MP-M had 16 2102 chips 
> for a total of 4K.  The memory address jumper chose which addresses that 4K 
> applied to.  So for example, if I set the jumper to 5, the card would occupy 
> $5000 to $5FFF?

Yes. Exactly.

> My question is, if I am correct that my second MP-M, having 32 RAM chips, has 
> 8K, and I've set it the jumper to '4', where does the other 4K of RAM go 
> beyond $4FFF?  It doesn't seem to go to $5000.   The instructions for 
> upgrading to the MP-MX spec don't say anything about having to modify the 
> card to span a greater address range, in fact, the jumpers for board # are 
> identical to the 4K MP-M.  So I'm confused.. what's the benefit of going out 
> to 8K if the board can't address more than 4?

Depends on how the modification was implemented.  I'm not familiar with those
mods so you will either have to reverse engineer what was done to figure out
how they are decoding the second bank on the board or remove the mod and
return the board to stock configuration.

It's possible that the mod enables the additional RAM at a fixed location
(such as $) and it is unrelated to where the jumper is set.  It's all
a matter of how they wired up the chip select(s) to the piggy backed RAMs.

> I'm sure it's something I'm missing here.

Understood.  Without documentation, it's a greater challenge.  The upside is
that these were very simple machines and pretty easy to understand once you
spend some time with them.  Lots of the secrets (of the system design anyway)
are here,

http://swtpc.com/

(with many thanks to Michael Holley for that archive)

Chris
-- 
Chris Elmquist

RE: RK05 packs

[tony duell]

> The other question is the disassembly of the pack and the installation 
> of the new hub.  How is that done?  What are the concentricity
> requirements for the platter?  Is there a mating surface (exterior cylinder
> surface on the hub) or are platter and hub aligned in some fixture and
> then clamped to hold the platter in position?  Clearly the pack would be
> reformatted, so a small amount of runout would be ok, but it would have
> to be small enough that the vibration is controlled.

I looked into this a couple of years ago with the intention of making
a 24 sector pack for an HP7900 (actually part of an HP9880). Starting
from a 12 sector pack of course.

This project got interupted by a house move and I've not gone back
to it yet, but I did discover there is no alignment ridge or anything
between the hub and platter. The platter fits on the flat top of the 
hub, there is a clamping ring that is then screwed down to anchor
it. 

My intention was to put the hub on a spare spindle (I happen to 
have a load of RK05 drive spares), put the platter on, turn it round
by hand and use a lever-type dial gauge to get minimum run-out. 

-tony



paul

Re: UNIBUS M9312 ROM type identification

[JP Hindin]

On Tue, 6 Sep 2016, Don North wrote:

On 9/6/2016 9:23 AM, JP Hindin wrote:


Greetings;

My googlefu is failing me and I was wondering if someone might be able to 
help me identify one of the boot ROMs present in an M9312 bootstrap/term 
board. The board has three ROMs, an RX01 (042130), an RX02 (042131) and 
then a mystery code - 043127.


The M9312 ROM identification table does not list this ROM code - I suspect 
it _might_ be for a DSD combined 8" drive and Winchester disk box, but I'm 
under the impression this would appear as a DU device, and attempting to 
boot from DU gets an ILL CMD, suggesting otherwise. I tried all of the 
other possible mnemonics listed in the M9312 manual, so it doesn't appear 
to piggy-backing on any of those either.


My thanks;

 - JP

Octal word 042130 decodes as ascii "DX", which is the M9312 boot mnemonic for 
the RX01 drive/RX11 controller combo.


Octal word 042131 decodes as ascii "DY", which is the M9312 boot mnemonic for 
the RX02 drive/RX211 controller combo.


Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
mnemonic. Probably a third party manufacturer custom boot prom.


FYI the above octal words are programmed in the first word of each boot PROM, 
so they are accessible at locations 773000,


You can find program listings and hex PROM images of all the known M9312 
devices here:  http://www.ak6dn.com/PDP-11/M9312/, including the DX and DY 
PROMs.


It didn't even occur to me that this was octal encoded ASCII, this is 
great, thank you. As Al suggests, it is going to an SMS device, so it 
looks like we've got a winner.


I managed to get an RX01 (although it's an RX02 box, took me a while to 
figure that one out) hooked up with what are supposed to be bootable 
disks,  but I get a Boot Error each time - so I think I have something 
probably off in the hardware, but in _theory_ the SMS is supposed to have 
a bootable OS image on its Winchester from the 1990s, so that might be 
interesting...


Thanks all!

 - JP

Re: RK05 packs

[Paul Koning]

> On Sep 7, 2016, at 2:51 AM, Pontus Pihlgren  wrote:
> 
> On Wed, Sep 07, 2016 at 01:58:24AM -0400, Ethan Dicks wrote:
>> On Tue, Sep 6, 2016 at 12:11 PM, Marc Howard  wrote:
>>> It seems to me that one possible solution would be to whip up a PLL in a
>>> CPLD or FPGA to generate 12 sector timing from a 16 sector pack or vice
>>> versa.
>> 
>> This is one of the recurring conversations here - 12-sector packs are
>> abundant compared to 16-sector packs, and the only difference is the
>> slits in the hub and the consequent formatting on the matching
>> controller...
>> 
>> -ethan
> 
> I do recall discussion of manufacturing new hubs but not the outcome. I 
> imagine that someone with access to a lathe and mill would be able to 
> make new hubs with good enough tolerances.
> 
> Is there some caveat to doing this (besides finding someone with a lathe 
> and mill?)

As one who has a (quite old) lathe and some limited skills in using it, I'd 
offer some.

You can't make something without having accurate specs -- engineering drawings 
or equivalent.  The sector mark ring isn't too terribly criticall, but the hub 
mating surfaces for the spindle are.  One question would be what the required 
tolerances are, and what the required surface finish is.  Depending on those, 
the job may be straightforward for a basement machine shop like mine, or they 
may require more than average skill and/or a high end CNC machine.  If the 
finish or tolerance requirements are sufficiently tight, the job might require 
grinding, which raises the difficulty to a whole new level.

The other question is the disassembly of the pack and the installation of the 
new hub.  How is that done?  What are the concentricity requirements for the 
platter?  Is there a mating surface (exterior cylinder surface on the hub) or 
are platter and hub aligned in some fixture and then clamped to hold the 
platter in position?  Clearly the pack would be reformatted, so a small amount 
of runout would be ok, but it would have to be small enough that the vibration 
is controlled.

paul

Re: Odd memory error in PDP-11/04

[Noel Chiappa]

> From: Ethan Dicks

Let's look at this one first, this is probably the easier to solve.

>>> 2) Setting D10 in location 00 results in D10 set in all the
>>> locations

>> Sorry, didn't follow that? Did you mean that if you store 02000 in
>> location 0, all other locations now report the 02000 bit set?

> Only 04000, but, yes.

Ah. That's D11. :-)

> If I set that bit in location 0, or other locations, it gets set in all
> locations. If I clear that bit, it clears.

So that's likely in the memory (although I suppose it could be the CPU,
_somehow_). It sounds like there's a latch somewhere in the output path
(because it affects all locations right away, not just once you've written to
them) that's getting set one way or the other, and and then, won't change. I
suspect the problem is with the flop for that bit, not in the circuitry
that's clearing/clocking that flop, since it only affects that one bit.

Looking at the MS11-J prints, there is indeed a '174 latch in the output
path; the one for D11 is in E30 (input pin 14, output pin 15). You might want
to throw a scope on it, and see if it is indeed acting consistently with the
symptoms (to make sure this is actually the cause).

Although why it can be either set or reset with a write, but freezes in one
state for reads, is puzzling. I'd suspect control circuitry, but it's only
that one bit. I don't think it can be something on the input side, because
the memory chips have input and output on separate pins, so if something was
hanging on the intput side, it shouldn't make it through the chip.

> Something appears to have died while I was powered-on and testing last
> night and now, the run light goes off right away after hitting boot,
> and I don't see the address lines or the data lines flickering.

Yeah, sounds like the CPU is halting. It's probably going to take a logic
analyzer to figure out what's going wrong. Too bad that machine doesn't have
a real front console, that would probably let you figure out what the problem
is.

Noel

Re: UNIBUS M9312 ROM type identification

[Al Kossow]

On 9/6/16 11:55 PM, Don North wrote:

> Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
> mnemonic. Probably a third party
> manufacturer custom boot prom.
>

It's probably for an SMS "FW" Floppy/Winchester.
That would be a good one to preserve.

http://bitsavers.org/pdf/sms/qbus/3000632E_FWT0100_FWT1100_Winchester_Floppy_System_OEM_Manual_Jul83.pdf

though I see in the manual it also had a Unibus as well as Qbus interface.

RE: SWTPC 6800 weirdness

[Brad H]

Ahhh.. okay, maybe I misunderstood.  I was reading '4096 words of 8 bit RAM', I 
don't know 'words' that well so I put it in a calculator and it was telling me 
it was 8K.  But docs suggested the original MP-M came with 2k.  So setting the 
board # jumper to 4, if it was at 2K, would run $4000 to $47FF, and with 4K 
runs to 4FFF, which is what that board is doing.

Phew.  So, it looks like I've got all the RAM working now.  The only address 
space I don't have covered is from $5000-7FFF.  Not sure if I'll need that.

So my next task is to run ROBIT.  However I'm still confused about that.  It 
says in the docs you want to set the highest and lowest significant bits of 
each of the lowest memory address and highest memory address to be tested.  But 
it doesn't explain at all how to do that.  It shows a listing for the program, 
but it looks like it's in assembly?  Does anyone know how I'd get the system to 
test, say, from $4000 to $4FFF, as an example?  Am I altering $A002 through 
$A005 using the monitor somehow?  Or do I need some kind of assembly language?

Thanks!!!

Brad

Re: HP-35/45 Simulator for PDP-8

[Kyle Owen]

On Sep 7, 2016 6:27 AM, "Eric Smith"  wrote:
>
> On Wed, Sep 7, 2016 at 12:10 AM, Kyle Owen  wrote:
> > Maybe the HP-41C simulator is next...
>
> That will definitely be entertaining.
>
> It will need three PDP-8 fields just for the 41C ROMs (12Kx10), and
> 400 words for the basic 41C RAM (16 "status" registers, 64
> data/program registers, all of 56 bits each).
>
> I think the 41CX might not fit, because it would need six fields for
> the 41CX ROMs, and 2320 words for the RAM (total 464x56). The
> simulator code and OS/8 would have to fit in less than 1.5 fields.

I could imagine OS/8 would come in handy here, as we could swap fields out,
maybe between several fields of ROM instructions, as kind of a cache
approach. There would be a ROM file that's required for use.

Hmm...but the biggest issue I see is the complex display, don't you think?
Maybe if we use a VC8E option...which would be fun to support for the
original simulator, too!

Kyle

RE: SWTPC 6800 weirdness

[Brad H]

-Original Message-
From: Chris Elmquist [mailto:chr...@pobox.com] 
Sent: Wednesday, September 7, 2016 6:13 AM
To: General Discussion: On-Topic and Off-Topic Posts ; 
Brad H ; 'General Discussion: On-Topic and 
Off-Topic Posts' 
Subject: RE: SWTPC 6800 weirdness

Both MIKBUG and SWTBUG need RAM at $a000.  Originally this was provided by a 
6810, 128-byte SRAM on the MP-A CPU board.  To run Flex and other stuff that 
wanted larger stack and workspace, people modified a 4K MP-M to reside at $a000 
(instead of somewhere below $8000) and then removed the 6810 from the CPU 
board.  This results in 4K of RAM at $a000 instead of 128 bytes but you need 
one or the other-- but not both and not neither  else the monitor won't run 
and without 4K, Flex won't run either.

Chris

On September 6, 2016 5:01:53 PM CDT, Brad H 
 wrote:
>
>
>-Original Message-
>From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of 
>william degnan
>Sent: Tuesday, September 6, 2016 2:52 PM
>To: General Discussion: On-Topic and Off-Topic Posts 
>
>Subject: Re: SWTPC 6800 weirdness
>
>>
>>
>> >
>> >
>> >Brad,
>> >You'll need to make electrical measurements, from the system
>checkout in
>> >the manual.   You very possibly will have marginal components that
>need to
>> >be replaced, but it's best to try to locate which is bad rather that
>
>> >to
>> replace at random.
>>
>> >A000 is not the same place as 0100.In the 64K space, they're
>quite
>> >distant.
>>
>> >Eliminate all but the one RAM board, setting it to .  Test that
>> thoroughly, then add the next at the next RAM space beyond the first
>card.
>> >Continue until you have enough RAM for a minimal Flex boot.  It 
>> >should
>> tell you in the version of Flex you're using how much that is (24K?)
>
>> It's hard to do everything at ?>the same time, break it down into
>chunks..
>> >Bill
>>
>> Thanks Bill.  I've tried working with just single RAM boards, but
>like
>> I said, the only one that will work at all is this modified board.  I
>
>> have pics of it here:
>>
>>
>https://drive.google.com/folderview?id=0B4pq0-BHd2x6WVFiZHdyMHBlNW8
>> p=
>> sharing
>>
>> If I could understand better what it is set up to do, what address 
>> spaces its occupying, I might be able to understand why my 16K DRC 
>> boards don't work when I try to put them to $A000.  I'd prefer to
>work
>> with one of those boards first since the chips are socketed, and then
>
>> I could test the chips individually and be sure one whole board is
>good.
>>
>> I note in one of my pics there, the cap on that modified MP-M looks a
>
>> little tarnished on the outside...
>>
>>
>>
>>
>>Getting a memory map of your system is an important step.  You need to
>know what memory addresses each board is attempting to use, so that 
>there is no
>>overlap.  Also remember that the ROM board has RAM on it too.   You
>would
>>not want to map both boards to the same A000 space, but why do you
>need this at all?  What wants free RAM there?
>
>>One important rule is that you don't want to overlap RAM.
>
>>Can you get to a monitor prompt without any RAM installed other than
>that which is in the ROM board?
>
>>b
>
>Based on what I've read, you *have* to have A000 if your CPU card has 
>been modified for Flex 2.0, which I've verified mine has.  When mods on 
>the older MP-A cards are done apparently it disables the onboard RAM, 
>and that's where A000 would be.  I could reverse the mod but I'm not 
>sure if I want to forgo FLEX use.  So yeah, according to SWTPC.com 
>since that mod was done, I have to have a board at $A000.  However, 
>setting either of my configurable ram boards to that space doesn't 
>work.  The system will only boot with that weird MP-M in.  So there's 
>more to it than that.. probably mods above and beyond.
>
>I suppose it wouldn't be too bad to just reverse the Flex 2.0 mods and 
>start there.  I'm doubtful if I'd ever use it and I could always 
>reverse again if I do..

Thanks Chris.  I figured it was something like that with my first MP-M.  I am 
curious though why simply setting another board to cover 8000-BFFF won't allow 
the system to operate in that board's absence.  It bothers me that I'm reliant 
on that heavily modded unit to be able to operate.

I have another general question for folks out there.  I'm trying to understand 
exactly how memory addressing works in relation to these boards.  For example, 
if I understand correctly, the original MP-M had 16 2102 chips for a total of 
4K.  The memory address jumper chose which addresses that 4K applied to.  So 
for example, if I set the jumper to 5, the card would occupy $5000 to $5FFF?

My question is, if I am correct that my second MP-M, having 32 RAM chips, has 
8K, and I've set it the jumper to '4', where does the other 4K of RAM go beyond 
$4FFF?  It doesn't seem to go to $5000.   The 

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Pete Turnbull]

On 07/09/2016 13:02, Noel Chiappa wrote:

From: Pete Turnbull



all microPDP-11/73 machines had an M8190. The M8192 was mostly sold
as an OEM board.


That's so bizarre (although the "Supermicrosystems Handbook", which
covers the 11/73, confirms it used the KDJ11-B).


As does the MicroPDP-11 Systems Maintenance Manual, the Micro-PDP-11 
Handbook, some Micronotes, the MICRO/PDP-11 Technical Manual, the IPB, ...



So the KDJ11-A
(M8192) was not used in any 'PDP-11/xx'?


Unless DEC sold something like a PDP-11/73S in a BA11-S chassis (like a
PDP-11/23plus), it was only used for OEM systems and customer-fitted
upgrades.


The other thing that makes no sense is that the KDJ11-B (M8190) has
all that extra circuitry on it to support PMI, etc - all of which is
unused in the 11/73 application! Why not just plug in a (presumably
cheaper) M8192? In the /73 application, the two are basically
equivalent. (OK, there are two built in serial lines on the M8190 -
big whoop.) Both have 8KB caches (although the one in the M8190 has
slightly fancier tagging, IIRC), etc, etc. Maybe it's the ROM (which
the M8190 has, but not the M8192)?


Don't forget the LTC :-)  All in all it saves a decent amount of 
backplane space, makes field service easier, and follows DEC's attempts 
to integrate as much as possible.  Otherwise, you'd need an additional 
bootstrap card such as an MRV11-D with -B2 boot ROMs, a DLVE1 (DLV11-JE) 
for the SLUs, something with an LTC, and termination.  That's at least 
twice as many slots in a Q-Q backplane and four slots in Q-CD.  A BDV11 
wouldn't work as it doesn't have the ROM capability (well, one of mine 
does but it's been seriously modified, well beyond the ECO for 22-bit 
:-)).  OK, you could use an MXV11-B with -B2 boot ROMs, but that's an 
expensive way unless you just want a very small (and slower) system, and 
you might still need termination.


And don't forget that DEC sold the microPDP-11/73 as a lower-cost 
alternative to the microPDP-11/83 which didn't appear until slightly 
later, or looking at it another way, as a fancier and faster 
microPDP-11/23.  The very first boards had some ASIC/J-11 problems that 
meant they wouldn't work with an FPJ11, and the first J-11 CPUs wouldn't 
run nearly as fast as intended so they were fitted with 15MHz crystals 
(as-sold-by-DEC 11/83 systems have 18MHz crystals).  I couldn't possibly 
imply they were finding a way to sell the inferior parts.  After that 
it's probably all marketing differentiation.


--
Pete
Pete Turnbull

Re: Odd memory error in PDP-11/04

[Ethan Dicks]

On Wed, Sep 7, 2016 at 8:35 AM, Noel Chiappa  wrote:
> > From: Ethan Dicks
>
> > What's happening now . is when I change one location .. it
> >  echoes across multiple locations...
> > ...
> > 1) Depositing any value is echoed 20 later.
> > ...
> > Does this sound like a dodgy CPU, dodgy RAM or both?
>
> It could be either. One possible cause of the symptoms you're seeing is that
> address line A04 on the bus is being held to one value (high or low) by
> something on the bus, so that whether the CPU tries to set it to 0 or 1, it
> has no effect. Also, of course, there could be some fault in the CPU, so that
> when it tries to do something with address 0, it gets 020 (or vice versa).
> And similarly for the memory.
>
> I'd try to write a small (two instruction) loop that sets that address line
> high/low (e.g.:
>
> 5037CLR @#1020
> 1020
> 775 BR  .-4
>
> and look and see if that address bit is flickering on/off on the UA11 (it will
> be on, but dully; constant assertion is bright on, constant de-assertion is
> full off). If so, the problem is almost certainly in the memory; if not, it
> could be either.

Once I get the console ODT to show up again, I will try that.
Something appears to have died while I was powered-on and testing last
night and now, the run light goes off right away after hitting boot,
and I don't see the address lines or the data lines flickering.

> > 2) Setting D10 in location 00 results in D10 set in all the
> > locations
>
> Sorry, didn't follow that? Did you mean that if you store 02000 in location
> 0, all other locations now report the 02000 bit set?

Only 04000, but, yes.  If I set that bit in location 0, or other
locations, it gets set in all locations.  If I clear that bit, it
clears.

I won't be able to enter 5037 / 1020 / 775... it will read back as
1037 / 1020 / 775 based on my previous work (depositing 1020 will
"turn" 5037 to 1037...)

-ethan

Re: vt100 terminfo with padding for an actual vt100?

[geneb]

On Tue, 6 Sep 2016, Cameron Kaiser wrote:


Interesting. I've been trying to get a WiFi device for the Commodore
8-bits working consistently in 9600 bps mode, and have just been
assuming the garbage characters I get when I receive a screenful of text
all at once were due to buffer overruns. The garbage characters there
look like actual garbage, not like partial CSIs like [3;1m or whatever.


Unless you're using an ACIA cartridge, 9600bps on the C128 is problematic,
and impossible on the C64.

FYI, you can do 38.4k on a C-64.  The driver for the Comet 64 modem does 
it on the user port.  Here's a link to the driver:

https://www.commodoreserver.com/BlogEntryView.asp?BID=FFB55F09EA4348BE921BCC59BAA725C6=9ABF9EE56AF3486AB8B167F2BEC327DF

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: RK05 packs

[Noel Chiappa]

> From: Ethan Dicks

> 12-sector packs are abundant compared to 16-sector packs

Really? Most of the RK05 packs I've seen for sale on eBay in the last couple
of years have been 16-sector - so I naturally assumed they were more common.
Well, I guess that explains why my offer to trade drew such a response! :-)

Noel

Re: 11/04

[Ethan Dicks]

On Wed, Sep 7, 2016 at 1:26 AM, Paul Anderson  wrote:
> Hi Ethan,
>
> If you are going to VCF and I go, I'll Try to throw a MS11-JP in the van
> for you.

Hi, Paul,

I am going.

> It's yours for bugging the guy with the H960s one more time.

I'll give him a shout.  I won't be able to fit in a visit before I hop
in the car at the end of the week, but I can try to reach him.

> That should save you some chip chasing time.

It could.  I do have multiple MS11-LD boards, but one per PDP-11/34
boardset, so I don't mind testing with them, I really do want a
dedicated board to stay with the 11/04.  It seems from the behavior
that it's not a RAM fault so much as a demux fault or even something
wrong in the CPU (bad 74181) or, given the dual symptoms, faults in
both.  Jason Timmons has promised me a DD11-PK if we can find it at
his house, then I could switch to testing with PDP-11/34 boards, and I
have multiple sets of those, all untested.  My BA11-L has the larger
power supply, so it should be no problem to test the FP11-A I found,
once I am confident of the rest of the machine.

-ethan

Re: Odd memory error in PDP-11/04

[Noel Chiappa]

> From: Ethan Dicks

> What's happening now . is when I change one location .. it
>  echoes across multiple locations...
> ...
> 1) Depositing any value is echoed 20 later.
> ...
> Does this sound like a dodgy CPU, dodgy RAM or both?

It could be either. One possible cause of the symptoms you're seeing is that
address line A04 on the bus is being held to one value (high or low) by
something on the bus, so that whether the CPU tries to set it to 0 or 1, it
has no effect. Also, of course, there could be some fault in the CPU, so that
when it tries to do something with address 0, it gets 020 (or vice versa).
And similarly for the memory.

I'd try to write a small (two instruction) loop that sets that address line
high/low (e.g.:

5037CLR @#1020
1020
775 BR  .-4

and look and see if that address bit is flickering on/off on the UA11 (it will
be on, but dully; constant assertion is bright on, constant de-assertion is
full off). If so, the problem is almost certainly in the memory; if not, it
could be either.

> 2) Setting D10 in location 00 results in D10 set in all the
> locations

Sorry, didn't follow that? Did you mean that if you store 02000 in location
0, all other locations now report the 02000 bit set?

Noel

Re: UNIBUS M9312 ROM type identification

[william degnan]

On Sep 7, 2016 1:08 AM, "JP Hindin"  wrote:
>
>
> Greetings;
>
> My googlefu is failing me and I was wondering if someone might be able to
help me identify one of the boot ROMs present in an M9312 bootstrap/term
board. The board has three ROMs, an RX01 (042130), an RX02 (042131) and
then a mystery code - 043127.
>
> The M9312 ROM identification table does not list this ROM code - I
suspect it _might_ be for a DSD combined 8" drive and Winchester disk box,
but I'm under the impression this would appear as a DU device, and
attempting to boot from DU gets an ILL CMD, suggesting otherwise. I tried
all of the other possible mnemonics listed in the M9312 manual, so it
doesn't appear to piggy-backing on any of those either.
>
> My thanks;
>
>  - JP

Most ROM part numbers for the 9312 end in A9.I suggest you're looking
up the wrong numbers.  I have a list on my site, but the following is more
comprehensive:

http://www.ak6dn.com/PDP-11/M9312/

Bill

11/04

[Paul Anderson]

Hi Ethan,

If you are going to VCF and I go, I'll Try to throw a MS11-JP in the van
for you.
It's yours for bugging the guy with the H960s one more time.

That should save you some chip chasing time.

Thanks, Paul

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Noel Chiappa]

> From: Pete Turnbull

> all microPDP-11/73 machines had an M8190. The M8192 was mostly sold as
> an OEM board.

That's so bizarre (although the "Supermicrosystems Handbook", which covers
the 11/73, confirms it used the KDJ11-B). So the KDJ11-A (M8192) was not used
in any 'PDP-11/xx'?

The other thing that makes no sense is that the KDJ11-B (M8190) has all that
extra circuitry on it to support PMI, etc - all of which is unused in the
11/73 application! Why not just plug in a (presumably cheaper) M8192? In the
/73 application, the two are basically equivalent. (OK, there are two built in
serial lines on the M8190 - big whoop.) Both have 8KB caches (although the one
in the M8190 has slightly fancier tagging, IIRC), etc, etc. Maybe it's the ROM
(which the M8190 has, but not the M8192)?

Noel

Re: HP-35/45 Simulator for PDP-8

[Eric Smith]

On Wed, Sep 7, 2016 at 12:10 AM, Kyle Owen  wrote:
> Maybe the HP-41C simulator is next...

That will definitely be entertaining.

It will need three PDP-8 fields just for the 41C ROMs (12Kx10), and
400 words for the basic 41C RAM (16 "status" registers, 64
data/program registers, all of 56 bits each).

I think the 41CX might not fit, because it would need six fields for
the 41CX ROMs, and 2320 words for the RAM (total 464x56). The
simulator code and OS/8 would have to fit in less than 1.5 fields.

Re: More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

[Pete Turnbull]

On 07/09/2016 03:32, Jules Richardson wrote:

On 09/06/2016 08:58 PM, Noel Chiappa wrote:



As far as I know, all the M8190's are _basically_ the same: they are the
KDJ11-B CPU, which support the PMI memory bus, can operate with a
KTJ11-B to
provide a UNIBUS, etc. They are the CPU in an 11/83 (with QBUS only
backplane) and the 11/84 (with QBUS/UNIBUS backplane).



I got the /73 reference from a post of Pete's last year:

http://www.classiccmp.org/pipermail/cctech/2015-February/002612.html

... but I' m guessing he just meant that the slower ones work at the
same speed as a true /73?


Well, in a sense the slower ones /are/ 11/73s.  By that I mean that all 
the microPDP-11/73s that DEC sold were (AFAIK) running at 15MHz and all 
the 15MHZ boards were sold as 11/73s - but all microPDP-11/73 machines 
had an M8190.  The M8192 was mostly sold as an OEM board.


Don't believe (let alone rely on) the Wikipedia article about the 
PDP-11/73 - it's just wrong.



Unfortunately there aren't any markings on the crystal on the -AB board
(well, there probably are, but on the underside and it would have to be
desoldered) so I don't know if it's a 15MHz or 18MHz part.


Look at the ROMS; if they're really early ones it's probably a 15MHz board.


--
Pete
Pete Turnbull

Re: Components available

[Mark Linimon]

On Wed, Sep 07, 2016 at 08:55:40AM +0200, Pontus Pihlgren wrote:
> Wow, what an attitude.. I don't know much about Unicomps but should 
> lesser know machines but unusual machines be preserved as well?

Well ... I imagine they already have decades worth of stuff to sort
through.  (I am intending to send them more soon :-) )

If you browse their online catalog your eyes will glaze over pretty
quickly.

That said, I do hope this machine is not scrapped.

mcl

Re: Y Combinator is restoring one of Alan Kay's Xerox Alto machines

[curiousmarc3]

> On Sep 5, 2016, at 9:30 AM, Josh Dersch  wrote:
> 
> At the LCM, I used an Apple II to test out the Alto's memory -- the Alto II 
> XM uses 4116 RAM chips.  I swapped in a row at a time and wrote a little 
> BASIC program to test for obvious errors.  This was time-consuming, but 
> eliminated the obviously bad chips, which helped immensely.

Oh, that's so simple and clever! Are these 16k chips? I don't have an Apple II, 
but I wonder if I could use the same trick and plug them in my HP 85 for which 
I just managed to burn the service ROM, which has a memory test built in.
Marc

Re: Components available

[Lyle Bickley]

On Tue, 6 Sep 2016 22:43:05 -0700
Bob Rosenbloom  wrote:

> .
> 
> > On Sep 6, 2016, at 6:16 PM, Al Kossow  wrote:
> > 
> > 
> >   
> >> On 9/6/16 4:18 PM, Tom Gardner wrote:
> >> 
> >> A friend of mine died recently; he was amongst many things an
> >> electronics tinkerer and has a closet full of small parts in bin
> >> cabinets (resistors, capacitors, ICs, transistors, hardware,
> >> etc.).  
> > 
> > 
> > There is also a Unicomp 18 bit minicomputer, paper tape reader, and
> > FFT processor circa 1972 in the garage (6ft rack) with full
> > documentation.
> > 
> > I walked out of the donations meeting with the other curators today
> > who thought it was a piece of s**t and didn't want to take it,
> > calling it a 'dumpster fire'
> > 
> > Art was a friend of mine.
> > 
> > Hopefully it can go someplace where it can be appreciated.
> > Talk to Tom about it, unfortunately, time is short.
> >   
> 
> I have room for it. I emailed and called Tom so at least it should
> not get scrapped. Wish it had a real front panel though.

I called and talked to Tom as well. So have other Bay Area folks. I
suspect that very little, if any, will be scrapped.

Cheers,
Lyle
-- 
73  AF6WS
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"

Re: The huge lot that had the NIB 8" floppies is now on ebay

[Pontus Pihlgren]

On Tue, Sep 06, 2016 at 11:30:39AM -0400, Noel Chiappa wrote:
> > From: Jason Howe
> > when folks just dump an ebay item number rather than a full link, those
> > posts should die
> 
> Why? It's a tiny bit more work to use them (prepend the number with the
> string "http://www.ebay.com/itm/;, and away you go), so one can't just click
> and go, but are people really that unwilling to go to the slightest effort?
> 

Also firefox has a nifty feature called "keyword search". If you 
rightclick the searchfield on ebay you can choose:

 "Add a Keyword for this search..." 

That lets you add a bookmark with a keyword field, enter something short 
like the letter "e".

Now you can type "e " in the address field, and it usually 
gives you a hit (sometimes ebay fails... ebay is a mess).

It's really handy, a wikipedia search is no "w " for me.

/P

Re: Components available

[COURYHOUSE]

In a message dated 9/6/2016 11:55:46 P.M. US Mountain Standard Time,  
pon...@update.uu.se writes:

On Tue, Sep 06, 2016 at 06:16:23PM -0700, Al Kossow wrote:
>  
> I walked out of the donations meeting with the other curators today  
> who thought it was a piece of s**t and didn't want to take it,  calling 
> it a 'dumpster fire'
> 

Wow, what an attitude..  I don't know much about Unicomps but should 
lesser know machines but  unusual machines be preserved as well?

/P

Right on... 
All machines are  part of the overall history, true, some more  significant 
than others but... ALL have a place.
Good thing about lists like  this is someone can be found to adopt  some of 
these systems.Ed# 

Re: UNIBUS M9312 ROM type identification

[Don North]

On 9/6/2016 11:55 PM, Don North wrote:

On 9/6/2016 9:23 AM, JP Hindin wrote:


Greetings;

My googlefu is failing me and I was wondering if someone might be able to 
help me identify one of the boot ROMs present in an M9312 bootstrap/term 
board. The board has three ROMs, an RX01 (042130), an RX02 (042131) and then 
a mystery code - 043127.


The M9312 ROM identification table does not list this ROM code - I suspect it 
_might_ be for a DSD combined 8" drive and Winchester disk box, but I'm under 
the impression this would appear as a DU device, and attempting to boot from 
DU gets an ILL CMD, suggesting otherwise. I tried all of the other possible 
mnemonics listed in the M9312 manual, so it doesn't appear to piggy-backing 
on any of those either.


My thanks;

 - JP

Octal word 042130 decodes as ascii "DX", which is the M9312 boot mnemonic for 
the RX01 drive/RX11 controller combo.


Octal word 042131 decodes as ascii "DY", which is the M9312 boot mnemonic for 
the RX02 drive/RX211 controller combo.


Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
mnemonic. Probably a third party manufacturer custom boot prom.


FYI the above octal words are programmed in the first word of each boot PROM, 
so they are accessible at locations 773000,


You can find program listings and hex PROM images of all the known M9312 
devices here:  http://www.ak6dn.com/PDP-11/M9312/, including the DX and DY PROMs.


Don


Whoops I sent before finishing this line:

FYI the above octal words are programmed in the first word of each boot PROM, so 
they are accessible at locations 773000, 773200, 773400, 773600 as 18b UNIBUS 
address.


Don

Re: UNIBUS M9312 ROM type identification

[Don North]

On 9/6/2016 9:23 AM, JP Hindin wrote:


Greetings;

My googlefu is failing me and I was wondering if someone might be able to help 
me identify one of the boot ROMs present in an M9312 bootstrap/term board. The 
board has three ROMs, an RX01 (042130), an RX02 (042131) and then a mystery 
code - 043127.


The M9312 ROM identification table does not list this ROM code - I suspect it 
_might_ be for a DSD combined 8" drive and Winchester disk box, but I'm under 
the impression this would appear as a DU device, and attempting to boot from 
DU gets an ILL CMD, suggesting otherwise. I tried all of the other possible 
mnemonics listed in the M9312 manual, so it doesn't appear to piggy-backing on 
any of those either.


My thanks;

 - JP

Octal word 042130 decodes as ascii "DX", which is the M9312 boot mnemonic for 
the RX01 drive/RX11 controller combo.


Octal word 042131 decodes as ascii "DY", which is the M9312 boot mnemonic for 
the RX02 drive/RX211 controller combo.


Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
mnemonic. Probably a third party manufacturer custom boot prom.


FYI the above octal words are programmed in the first word of each boot PROM, so 
they are accessible at locations 773000,


You can find program listings and hex PROM images of all the known M9312 devices 
here:  http://www.ak6dn.com/PDP-11/M9312/, including the DX and DY PROMs.


Don

Re: Components available

[Pontus Pihlgren]

On Tue, Sep 06, 2016 at 06:16:23PM -0700, Al Kossow wrote:
> 
> I walked out of the donations meeting with the other curators today 
> who thought it was a piece of s**t and didn't want to take it, calling 
> it a 'dumpster fire'
> 

Wow, what an attitude.. I don't know much about Unicomps but should 
lesser know machines but unusual machines be preserved as well?

/P

Re: RK05 packs

[Pontus Pihlgren]

On Wed, Sep 07, 2016 at 01:58:24AM -0400, Ethan Dicks wrote:
> On Tue, Sep 6, 2016 at 12:11 PM, Marc Howard  wrote:
> > It seems to me that one possible solution would be to whip up a PLL in a
> > CPLD or FPGA to generate 12 sector timing from a 16 sector pack or vice
> > versa.
> 
> This is one of the recurring conversations here - 12-sector packs are
> abundant compared to 16-sector packs, and the only difference is the
> slits in the hub and the consequent formatting on the matching
> controller...
> 
> -ethan

I do recall discussion of manufacturing new hubs but not the outcome. I 
imagine that someone with access to a lathe and mill would be able to 
make new hubs with good enough tolerances.

Is there some caveat to doing this (besides finding someone with a lathe 
and mill?)

/P

Re: HP-35/45 Simulator for PDP-8

[Kyle Owen]

I updated the project to include optional OS/8 support. I won't say I've
tested it extensively, but it does seem to be working as expected in SimH,
anyways. I updated the README to reflect the additions. The directory
structure was also updated to something more sane.

The keen observer will note that I also changed up some of the debugging
features which are likely to not be useful to anyone other than the
author...and even then, I only used the features a few times when getting
the thing running initially. But, it's there if you need it, all
configurable through the switch register as detailed in the source.

Glad some folks got a kick out of it enough to try it out! Feel free to
suggest improvements where you see fit. I was thinking about adding support
to read keystrokes from a file for macro programmability...but that might
be too absurd even for this project. Maybe the HP-41C simulator is next...
:)

Kyle