Re: Memory Tech you don't see very often

[Eric Smith via cctech]

On Thu, Jan 6, 2022, 01:20 Joshua Rice via cctech 
wrote:

>
> Not cost effective at nearly $10,000! I understand they're very rare,
> given they were only used for a few years in industry and they're
> clocking on 3/4 of a century old, but even then, that seems an order of
> magnitude or two off the real value.
>

The rarity wasn't that only one _model_ of computer used it. Only one
_unit_ used it. It used 80 tubes at a cost of around $500 each, in
mid-20th-century dollars.

Given that they'd have needed some spares and replacements, the production
run would have been more than 80 pieces, but I'd think it unlikely that
more than 250 production units were ever made.

If someone wants one and is able to purchase it for $10,000, I think they
are very lucky.

Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives

[Eric Smith via cctech]

On Thu, Oct 1, 2020 at 11:54 AM dwight via cctech 
wrote:

> It is going to need a lot of contact cleaning.
> The one thing I like is the carry design the Zuse used. Really fast for
> relays but not of much use for solid state.
>

Where is that circuit described?

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctech]

On Wed, Apr 8, 2020 at 2:54 PM Eric Smith  wrote:

> That stands for "data field too big", i.e., too much data to fit in 4KW.
> That's as opposed to "instruction field", which if too big would mean that
> there's too much code.
> Although I used OS/8 Fortran in the distant past, I never tried to compile
> large Fortran programs or programs that used much data, so I don't know
> what it takes to solve that problem. Maybe there is some way to get Fortran
> to use more than one 4KW field for data, issuing the necessary CDF
> instructions to switch data fields?
>

Checking the OS/8 Language Reference Manual reveals that I was totally
incorrect.
That stands for Data File too big.
"Product fo number of record times number of blocks per record exceeds
number of blocks in file."
So I have no idea how to fix that.

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctech]

On Wed, Apr 8, 2020 at 1:34 PM Bill Degnan via cctech 
wrote:

> D.F. TOO BIG INIT  
> I'd really like to understand what this error means if
> anyone knows.
>

That stands for "data field too big", i.e., too much data to fit in 4KW.
That's as opposed to "instruction field", which if too big would mean that
there's too much code.
Although I used OS/8 Fortran in the distant past, I never tried to compile
large Fortran programs or programs that used much data, so I don't know
what it takes to solve that problem. Maybe there is some way to get Fortran
to use more than one 4KW field for data, issuing the necessary CDF
instructions to switch data fields?

Re: VAX & PDP-11 Stuff To Clean Out

[Eric Smith via cctech]

On Thu, Nov 7, 2019, 19:36 Jules Richardson via cctech <
cctech@classiccmp.org> wrote:

> On 11/6/19 12:16 PM, David Coolbear via cctech wrote:
> > M5976-AA KZQSA SCSI Controller Q
>
> Hmm, I could sure use one of those...
>

Be forewarned that a KZQSA isn't a "real" SCSI controller. It's doesn't use
MSCP, and doesn't emulate any better-supported controller. It only is
intended to support a few specific tape drives and CD-ROM drives. It's
supported in some versions of VMS; I'm not sure about Ultrix.

I don't think it can be used as a boot device, though I'm less certain
about that.

Re: ok I have to ask...confirm direction of GRANT continuity cards please

[Eric Smith via cctech]

On Thu, Jun 28, 2018 at 8:26 PM, Bill Degnan via cctech <
cctech@classiccmp.org> wrote:

> I have always pointed my grant continuity cards in the same direction as a
> NPG card, with the traces to the left/facing the last slot of the
> backplane.  I am 99% sure this is right but I was asked and I just want to
> be 100%...am I right?  In particular the traces point away from the CPU
> cards, at least on an 11/40 and 11/05.  Please just tell me I am not losing
> it.
>

If your system works properly, the grant cards are in the right way. If the
grant cards are installed wrong, or missing, it will cause serious
problems, and you're unlikely to be able to boot anything.

Re: 6800 fig-FORTH?

[Eric Smith via cctech]

On Sat, Jun 23, 2018 at 1:16 PM, Stephen Pereira via cctech <
cctech@classiccmp.org> wrote:

> Has anyone here ever seen or ever had fig-FORTH for the 6800 working?
>

In the mid-1980s I know someone with a WaveMate 6800 system. He had
fig-Forth running on FLEX.  At the time I was only interested in the Apple
II, DEC PDP-10, and BSD 4.x on VAX, so I didn't pay much attention to his
system.

I had problems similar to what you describe when I was bringing up the PACE
version of fig-Forth, and tracked down and fixed a serious bug in the
published listing. AFAICT, I am the only person other than the author who
ever ran the PACE version. I found it far easier to debug on a simulator
rather than the real hardware.

The 6800 version must surely have been far more popular than the PACE
version, so it seems somewhat unlikely that there would be a huge defect in
the published listing, but it's not impossible.

I wrote some 68HC11 assembly professionally in the late 1980s, but the only
actual 6800 code I've writen was a 6800 version of the Apple I monitor.
Writing 6800 code after being used to the 68HC11 and 6809 was a huge step
backward; I kept trying to use newer instructions and addressing modes that
the 6800 did not have.  I have a non-working Electronic Product Associates
Micro 68; maybe someday I'll fix it up.

Eric
N2ES

new disassembler vs IDA (was Re: 8085 Dissasembly?)

[Eric Smith via cctech]

On Wed, Apr 18, 2018 at 8:17 PM, Mark J. Blair via cctech <
cctech@classiccmp.org> wrote:

> Some of the future reverse engineering projects I have on my to-do list
> involve the CDP1802 processor, which IDA presently doesn't support. When I
> get to them I'll have to decide whether to use dismantler vs. learning how
> to add CDP1802 support to IDA. I'm leaning towards the latter, because IDA
> is so much fancier than dismantler is.


I'd vote for adding it to dismantler.

I had an IDA Pro license at one point, but I seem to have misplaced it, and
it is too old to get me any discount on a new release.  I imagine that IDA
has probably improved a lot since back then, but at the time it had a
pretty awful user interface.

If I had an actual business need to reverse-engineer something using a
processor that IDA supported, I'd certainly buy a new IDA license, but I
wouldn't personally invest any time in building add-ons for expensive
commercial software, when there are open source alternatives that may not
be as good, but are generally good enough.

For the 1802, I've used a really crude disassembler written in C. The 1802
instruction set isn't very complicated, so a disassembler for it isn't
either.  It's been so many years since I actually disassembled 1802 code
that I'm not sure I still have the disassembler around.

Re: who is in this picture? (VCF 199x)

[Eric Smith via cctech]

On Tue, Jan 30, 2018 at 2:55 PM, Bill Degnan via cctech <
cctech@classiccmp.org> wrote:

> https://retropopplanet.files.wordpress.com/2011/06/vintage-computer.jpg
>

Pavl Zachary

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

[Eric Smith via cctech]

IBM invented computer emulation and introduced it with System/360 in 1964.
They defined it as using special-purpose hardware and/or microcode on a
computer to simulate a different computer.

Anything you run on your x86 (or ARM, MIPS, SPARC, Alpha, etc) does not
meet that definition, and is a simulator, since those processors have only
general-purpose hardware and microcode.

Lots of people have other definitions of "emulator" which they've just
pulled out of their a**, but since the System/360 architects invented it, I
see no good reason to prefer anyone else's definition.

Re: Importing a PDP-8 from Canada

[Eric Smith via cctech]

On Mon, Jul 31, 2017 at 6:15 PM, Michael Thompson via cctech <
cctech@classiccmp.org> wrote:

> The RICM has an opportunity to get a PDP-8/M (built in Maynard, MA) that is
> in Canada. I remember that there was a discussion on the procedure here,
> but I can't find it with Google.
>

If it is actually bears a label stating the origin as the US, then there's
nothing special to do, other than show that label to the customs official
if they don't take your word for it.

Re: Firefly dual processor card

[Eric Smith via cctech]

Did you get an actual Firefly (research) board, or a prduction VAXstation
3520/3540 board? I don't think you're likely to find schematics or pinouts
for either, but it's not impossible to find 3520/3540 stuff, while I've
never before heard of anyone encountering any actual Firefly boards in the
wild.

Re: Extracting files off “unknown” 8 inch disks. Any thoughts…

[Eric Smith via cctech]

On Fri, May 5, 2017 at 3:02 PM, allison via cctech 
wrote:

> In the PDP-10 realm not less than a handful Tops10. ITC, more.
>

TOPS-10 doesn't have any filesystems for floppy disks, though the KL10
front-end PDP-11/40 running RSX-20F does, and there are utilities to access
RSX and RT11 filesystems from TOPS-10.

AFAIK, the situation is the same for TOPS-20.  I don't have any idea
whether ITS, WAITS, Tenex, or the Compuserve Monitor ever had any different
floppy disk support.

Re: Information Request: unidentified HP 9825T instructions

[Eric Smith]

On Mon, Feb 13, 2017 at 12:35 PM, Tony Duell  wrote:

> That seems possible, yes.
>
> Having other hardware decode instructions that appear as NOPs to the main
> processor is not uncommon in HP machines.
>

And it's even common in HP machines for such instructions to be used for
ROM bank switching.

Re: Altair 8800 name Was: Re: Altair 680 Expansion Boards?

[Eric Smith]

On Thu, Dec 22, 2016 at 7:01 PM, drlegendre .  wrote:

> The Z80 also showed up in the Osborne, Kaypro and TRS-80 models.. mostly
> due to the fact that CP/M was written to it.
>

Use of the Z80 in the mainstream TRS-80 models (1 and III) had little or
nothing to do with CP/M.  The special CP/M with a non-standard TPA needed
for the Model 1 and III was just about useless, since it would only run
special TRS-80 versions of CP/M software. There were third-party mods for
the Model 1 and III to run a normal CP/M, but only a tiny fraction of
TRS-80 users did that.

CP/M may have been more of a factor for the Model II/12/16/6000, which
could run a normal CP/M without any hardware mods, as could the later Model
4 and 4P.  Most Model II family machines I saw in the wild were used to run
Radio Shack's accounting and business software on TRS-DOS II; few used
CP/M, possibly because there were much lower cost CP/M systems available
elsewhere.  Most Model 4 owners I knew didn't do any serious CP/M use on
it, and mostly used the 4 as an improved-spec III running TRS-DOS/LDOS/etc.

Re: ADM-3A Lower case ROM issue

[Eric Smith]

>From the ADM3A Maintenance Manual, page 6-11:

The two character generator ROMs are rather straightforward. The upper case
> ROM is a standard masked part (2513) but the lower case ROM is a custom
> masked part. The one unusual thing about this is that all of the address
> lines into the lower case character generator are inverted.
>

That refers to the character code address inputs to the ROMs; the line
address is common between the two.

The character addresses for the ROMs come from two 74LS175 four-bit latches
at K13 and L13, which have both inverting and non-inverting outputs.  The
non-inverting outputs go to the UC 2513 ROM (L15), while inverting outputs
go to the LC ROM (L14).

>From the schematic, the only TTL chip that appears to be needed solely for
the LC option is the 74LS157 at K12, but I'm not sure whether a UC-only
model would work without that installed. The manual doesn't show that part
as optional. My UC-only ADM3A does have it.

Upgrading from UC to UC/LC does require adding the H11 and J11 RAM chips
for the seventh bit of the refresh memory. Only one of the RAMs has to be
installed for a 12-row-ony model.

Re: Could somebody please help me identify this board?

[Eric Smith]

On Wed, Dec 7, 2016 at 9:28 PM, Eric Smith <space...@gmail.com> wrote:

> Given that it's extended length anyhow, and thus not compliant with the
> bus spec, it doesn't really matter which side of the board the components
> are on, other than it precludes use in some backplane slots. I may have
> been designed that way to fit in a specific slot in a specific machine.
>

On the other hand, the pin count on the wider edge connector is 100 rather
than 86 so not Multibus.

Re: Could somebody please help me identify this board?

[Eric Smith]

On Wed, Dec 7, 2016 at 5:34 PM, Michael Thompson <
michael.99.thomp...@gmail.com> wrote:

> > Extended-length Multibus.  Definitely not Multibus II, which uses
> Eurocard
> > 6Ux220 form factor with two 96-pin DIN 41612 connectors.
>
> The components are on the wrong side of the board for a Multibus.
>

Given that it's extended length anyhow, and thus not compliant with the bus
spec, it doesn't really matter which side of the board the components are
on, other than it precludes use in some backplane slots. I may have been
designed that way to fit in a specific slot in a specific machine.

Re: HP 9872 Refurbishment

[Eric Smith]

On Mon, Dec 5, 2016 at 11:20 AM, Craig Ruff  wrote:

> Also, since I have it apart, I thought it might be good to image the
> firmware ROM set.  They are marked Mostek MK36647N-5 and MK36648N-5, along
> with the HP part numbers.  From the schematic, they appear to be 5V 8KB
> ROMs, so nothing fancy should be required to read the contents.  It appears
> these might be MK36000N-5 mask programmed ROMs?
>

Yes. And same for the 9872T.

The 9872A uses HP ROMs that aren't compatible with anything else. I'm not
sure about the 9872B and 9872S.

Re: Supercomputers, fishing for information

[Eric Smith]

Around 1985, Tony Anderson of Intel gave me a tour of the Intel Scientific
Computers operations at their Oregon facility. At the time they were
building the 80286-based iPSC/1.  Seemed like pretty neat stuff.

That was where I learned that one shouldn't stick one's hands into a
computer while wearing metal jewelry (rings, watches, etc.), even if only
low voltages are present.  Fortunately I didn't have to learn it the hard
way.

Re: [TUHS] Booting PDP-11's from RX02's

[Eric Smith]

On Tue, Nov 1, 2016 at 3:53 AM, allison  wrote:

> On 10/31/2016 07:45 PM, Al Kossow wrote:
> >
> > On 10/31/16 3:08 PM, Vincent Slyngstad wrote:
> >
> >> Isn't there some weird crap in track 0 on DECmate RX01s
>
> It also has the slushware code, aka front panel space code to do
> stuff on the IM6100 chip and peripherals.  the 6100/6120
> have two spaces front panel code space and normal PDP-8 memory.


Isn't the slushware on the last two tracks of the disk, rather than on
track 0?

Re: Looking for HP98034 / HP9895 ROM images

[Eric Smith]

On Tue, Oct 18, 2016 at 11:14 AM, Craig Ruff <cr...@ruffspot.net> wrote:

> I’ve sent F.Ulivi the contents of the single ROM version from my 9895A,
> along with some preliminary reverse engineering work on the contents that
> I’ve done in conjunction with Eric Smith.


I've put the partially reverse-engineered 9895A firmware on Github:
https://github.com/brouhaha/hp9895fw

So far we've figured out some of the Amigo command parsing and some of the
PHI chip accesses. (PHI was an HP custom SOS chip for HP-IB.)

Re: Unibus disk controller with modern storage

[Eric Smith]

On Wed, Oct 19, 2016 at 4:48 PM, shad  wrote:

> The board itself wouldn't be cheap at all, because PCB would be big,
>

True. From a Chinese vendor such as PCBway, a DEC quad size double-sided
PCB without ENIG (immersion) gold surface finish but without hard-gold edge
fingers costs $15.10 each in quantity 10, and a hex side PCB costs $20.40
each.  However, the ENIG gold is quite thin and won't withstand very many
backplane insertions.  The cheap PCB vendors don't offer hard gold edge
fingers. Jon Elson pointed out that E-TekNet in Arizona does offer hard
gold at better prices than some fab houses, but still a lot more than the
cheap Chinese PCBs.

I prefer NOT to use ENIG, as I find HASL tin-lead better for hand assembly,
though the lead is a problem due to RoHS regulations in much of the world
(but not in USA). I haven't tried HASL lead-free.


> and because FPGA aren't cheap either.
>

Xilinx XC6SLX9-2TQG144C is probably big enough for such things, and only
costs $16.52 in quantity 1 from Digi-Key.  It's in a TQFP, so not *too*
difficult to deal with. It has essentially 11,440 logic cells (5-LUT with
FF)*,  32 block RAMs of 18 Kbits each, and 102 3.3V I/O pins. It's not 5V
tolerant, but no modern parts are. 5V tolerance can be achieved in many
cases by the use of series resistors, but I like using the TI
SN74CBTD3861DGVR bus switch/voltage clamp, which can make 10 I/O pins 5V
tolerant at a cost of $0.62 in quantity 1. The bus switch is advantageous
over series resistors because it doesn't add much series resistance to pins
that are being used as outputs, and it has a maximum propagation delay of
0.25ns.

If you need more FPGA capability, the XC7A15T-1FTG256C has substantially
more resources, and costs $25.69 in quantity 1.  It's in a 256 ball BGA, so
somewhat harder to deal with, and needs at least a four layer board,
possibly even six layer.  However, it has 20,800 logic cells (5-LUT with
FF), 25 block RAMs of 36 Kbits each, and 170 3.3V I/O pins.

If you need more resources than that, it turns out that the XC7A15T,
XC7A35T, and XC7A50T are actually all the same die, just factor-programmed
with a different device ID. The 35T and 50T have double and triple the
logic cells and block RAMs of the 15T. The Vivado FPGA toolchain
artificially limits the resource usage of the two smaller parts, but
doesn't actually restrict which specific logic cells and block RAMs are
used, which means that the 15T and 35T have silicon that passes the factory
testing for ALL resources, not just 1/3 or 2/3 of them. It's been verified
that one can change the device ID in the bitstream, disable bitstream CRC
checking, and use the smaller part as a larger part. I don't like disabling
the CRC, because it serves to protect the FPGA from damage if the bitstream
has been corrupted, so I wrote a program that can both change the device ID
and recompute the CRC. I don't yet have a board with a 15T or 35T to test
with, but I'll release the program as open source once I do.

Because going to a 4 layer or 6 layer board is quite expensive when the
board size is large, e.g., DEC quad or hex size, I think it makes sense to
put the FPGA, its configuration flash, voltage regulators, and the bus
switches for 5V tolerance on a daughterboard. I've been working on such a
design, with two 96-pin DIN connectors for connection to the main board,
and at least 160 GPIOs available. The main board can then be just
double-sided, and possibly even 100% through-hole, for people that don't
want to hand-assemble boards with surface-mount components. The drawback is
that it will occupy more than one backplane slot due to the height.

There's still the problem that no current production bus interface ICs meet
Unibus, Qbus, or Omnibus specifications. Surplus DS8641 chips are
technically the best choice. With modern chips, it's necessary to use
separate drivers and receivers, and still difficult to meet the full specs.
Compromising the specs is possible but may make things unreliable in a
large system (multiple backplanes with cables, and many other cards).

Eric

* Xilinx has some other confusing definition of a "logic cell" for
marketing purposes, which is not the same as a LUT+FF. Oddly enough, their
marketing logic cell count is actually lower than a sensible accounting,
which is the opposite of how FPGAs used to be rated in exaggerated gate
counts, which we derided as "marketing gates".

The 6-series and 7-series actually have 6-LUTs with 2 FF each, but they can
be used as two 5-LUTs with 1 FF each, which is how I count them for
assessing the FPGA's logic capacity.

Re: large Wire wrap cards

[Eric Smith]

They look like Multibus (I).

Re: Unexpected Apple Lisa display - what is it?

[Eric Smith]

On Wed, Sep 28, 2016 at 1:02 PM, Paul McJones  wrote:
> I suspect it is a Macintosh utility (Disk Copy?) Lisas could run Macintosh 
> software using something called MacWorks.

It doesn't look like any version of DiskCopy I've seen, but I think
Paul is right about it being Mac software, since the Lisa OS doesn't
have "Finder".

Re: Decoding kryoflux stream for HP9895A

[Eric Smith]

On Tue, Sep 20, 2016 at 7:42 AM, Denise de Vries
 wrote:
> Does anyone know of documentation for the HP9895A format with its own M2FM 
> encoding?
> I have a kryoflux preservation stream but so far can make no sense of it.

I've successfully decoded Intel M2FM disks.  The track-level format
isn't the same as the HP 9895A, but the channel code is.  I'd be happy
to take a look at a 9895A image.

Re: dfitoimd: decoding Intel M2FM floppy flux images (was Re: Intel 432 floppy flux images for decoding)

[Eric Smith]

On Sun, Aug 7, 2016 at 8:53 PM, Jay Jaeger  wrote:
> Folks, I do have a version of software that supports READING Intel m2fm on a 
> cat weasel, and will post a link in the coming days - just got back from a 
> road trip.

That's great! I look forward to seeing it, even though I don't have a
Catweasel.  :-)

Re: 8 inch disks - help needed identifying format

[Eric Smith]

On Wed, Aug 3, 2016 at 3:19 AM, Rik Bos  wrote:
> It is a HP disc, probably for the hp 9845/35 series.
> H tells you the drive type (9895A), 8 the controller select code, 0 the drive 
> address, 1 the unit address (second disc in a unit, first disc will be 0).
> Probably the disc will contain a large fata file of 1188 blocks, may be it’s 
> a database can’t say much more of it. To determine the data itself you need 
> to know the first record of the file,they will tell the kind of data in it.

If it's a 9895A disk, and if it is double density, then the 9895A is
the only drive that can read the disk in the normal way, because HP
used their own unique M2FM format for that.

Of course, a flux-transition reader like Catweasel or DiscFerret can
be used to archive it, though AFAIK there's not yet any software that
understands 9895A format. The 9895A documentation doesn't give enough
detail on the format, so some reverse-engineering of the format
details would be needed to write suitable decoding software.

I'm currently working on a Python program to decode Intel M2FM format
(used for double density 8-inch with SBC-202 controller on MDS 800,
Series II, Series III) from flux transition data. The Intel M2FM
format is reasonably well documented.

Re: Z80 /WAIT signal question

[Eric Smith]

On Fri, Apr 22, 2016 at 12:26 PM, Eric Smith <space...@gmail.com> wrote:
> I thought at one point I saw Zilog or Mostek Z80 documentation
> that gave the specific details of every M cycle of every instruction,
> but I can find such a thing at the moment.  :-(

Found it. Section 12.0 of the Mostek MK3880 Central Processing Unit
Technical Manual, as found in the Mostek Microcomputer Z80 Data Book,
publication number 79602, August 1978. Also in the Mostek 1982/83 Z80
Designer's Guide, June 1982.

I'm still looking for the Z80 DMA Technical Manual.  **NOT** the data
sheet, I've got multiple copies of that.

Re: Z80 /WAIT signal question

[Eric Smith]

On Fri, Apr 22, 2016 at 3:15 AM, Alexis Kotlowy
 wrote:
> http://kaput.homeunix.org/~thrashbarg/z80.pdf
>
> Looking at this Z80 datasheet (page 20 of the PDF) the timing diagrams
> say the /WAIT signal is sampled on the falling edge of clock state T2.
> If it is active, additional cycles are introdced between T2 and T3. This
> only occurs on op-code fetch, memory reference, input-output and
> interrupt acknowledge cycles.

Thanks, but I'm not convinced by that particular part of the
datasheet. I see where it says:

1)  "The Z80 CPU executes instruction by proceeding through a specific
sequence of operations: *Memory read or write *I/O device read or
write *Interrupt acknowledge"

2)  "Machine cycles can be extended [...] by the insertion of one or
more Wait states by the user."

The first of those statements omits that there can be M cycles which
are of none of those stated cycle types, and are used purely for
internal operation. For example, an ADD HL, BC instruction has three M
cycles, but only the first is a fetch, and the other are internal
operations. The second and third M cycles have seven T-states between
them; probably one of those M cycles has three T-states and the other
has four[*].

I don't see where it says that ONLY the op-code fetch, memory
reference, input-output, and interrupt cycles can be extended, and I
don't see anything in the datasheet or user manual that definitively
states that the second and third M cycle of that 16-bit ADD
instruction can't be extended with wait states by /WAIT being asserted
at the faling edge of T2 of those M cycles.

On the other hand, if someone with personal experience has verified
that internal-only M cycles can't be extended by asserting /WAIT,
that's would answer my question. I'm starting to think that I'll
actually have to kludge up a test circuit to find out.

Best regards,
Eric

[*] I thought at one point I saw Zilog or Mostek Z80 documentation
that gave the specific details of every M cycle of every instruction,
but I can find such a thing at the moment.  :-(

Re: 21MX proms (per request

[Eric Smith]

On Fri, Sep 11, 2015 at 12:41 PM, GerardCJAT  wrote:
> HOW OFTEN theses old PROM fail  ??

Note that some bipolar PROMs suffer from fuse regrowth, where bits
that have been programmed gradually revert to an unprogrammed state.
This was a big problem with NiCr fuses. Later bipolar PROMs used
different fuse materials; TiW was one of the later choices. I don't
know whether TiW or other newer fuses have regrowth issues, but if
they do, it's slower than NiCr.

It is possible to recover the bits from a bipolar PROM with regrowth
by decap and optical inspection, because the regrowth happens in
relatively narrow tendrils which are visibly different than an
unprogrammed fuse.  I've actually seen that done.

There is speculation that it could be done without decap by trying to
blow each unblown fuse and measuring the energy required to blow the
fuse; a regrown one should require less energy. I'm not aware of
anyone actually having done it that way. I wouldn't trust a
one-of-a-kind PROM to that process.

Obviously it's best to dump the PROM contents before regrowth becomes an issue.

Re: Tu10 pdp11

[Eric Smith]

On Sat, Sep 5, 2015 at 7:54 PM, Jay Jaeger  wrote:
> Just to be clear, a TU10, even a master, does NOT connect directly to a
> PDP-11.  Instead, a cable of the same general ilk as a BC11 UNIBUS Cable
> (but I have not verified it is in fact the same kind of cable) connects
> the drive to the TM11 controller.

That's true, but a TM11 controller can be installed in the TU10 master cabinet.

Re: Tu10 pdp11

[Eric Smith]

On Fri, Sep 4, 2015 at 6:14 PM, william degnan  wrote:
> Reading docs on DEC TU10 for pdp 11 one makes a serial connection, right?
> Not sure because I found little about baud, etc.

No.

> I did not see any definitive controller card for UNIBUS pdp 11.  Maybe I am
> missing something..can anyone share experiences?

A TU10 master drive contains electronics[*] which allows it to be
interfaced to a PDP-11 TM11 tape control. Said electronics is probably
what's known as a formatter, though I haven't studied the TU10 in
detail so I'm not 100% certain.

A master TU10 can be used with up to seven TU10, TU20, TU30, or TU40
slave transports.

The TM11 controller has its own backplane, and may be mounted in the
TU10 master drive. It connects to PDP-11 using the usual BC11-A Unibus
cables.

Re: Reading ROMs

[Eric Smith]

On Thu, Sep 3, 2015 at 6:57 PM, Vlad Stamate  wrote:
> I am not sure about the part number it was under the sticker with the
> ROM version (which btw was 09121 15510 REV A) and I put it back into
> the unit.

The PCA silkscreen diagram in the service manual shows F2364, which is
an 8Kx8 masked ROM. The silkscreen shows a 28-pin footprint, but it is
not clear whether the device is a 24-pin or 28-pin chip. If it is a
24-pin chip, it should be possible to read it with an EPROM programmer
configured for the Motorola MCM68764 or MCM68766 EPROMs.  For an EPROM
programmer which does not support the MCM6876x, it's possible to wire
an adapter:

http://www.mess.org/dumping/2364_mask_roms

Re: 'New' PDP-11 prints

[Eric Smith]

>> Field Maintenance Print Set

On Thu, Sep 3, 2015 at 6:39 PM, steve shumaker  wrote:
> These are specifically defined
> sets of diagrams and/or schematics for a particular part/module/assembly?

Sometimes a module, sometimes an assembly, sometimes an entire
computer or computer system.  Some FMPS include nested FMPS for
subassemblies or modules.

The exact content of an FMPS varies quite a bit. Some are only
schematics, most also include component placement diagrams, some even
include the PCB etc patterns. Some include parts lists. Some include
wirelists but most do not. For processors, some include flow diagrams
or PROM contents.  It's whatever subset of the engineering drawings
that the service organization thought would be necessary or useful to
field service, so many things we might want from an historical
perspective are not included.

> Bound or loose sheet?

They are US B size (11 inch by 17 inch), stapled on the left edge, and
hole punched on the left edge for use in a large binder.

RE: Reforming capacitors (technical description, not politics)

[Eric Smith]

Time to reform is to a first approximation proportional to the rated
capacitance, rated voltage, and the length of time that the capacitor has
been unpowered. However, there is still a lot of variation. I've had a few
40-year-old capacitors (unused for at least 30 years) that took less than
two hours tp reform to 135% of rated voltage, but others of the same
ratings that took more than 48 hours.

I usually use a lab power supply with adustable current limiting. I adjust
the voltage in increments of 1V, and set the current limit to a different
computed limit for each voltage increment so that the maimum power (PS
current limit setting * PS voltage setting) doesn't exceed a value believed
to have no risk of damage to the capacitor.

(This is basically the PDP-1 capacitor reformation procedure devised by Bob
Lash, except the voltage increments were 0.5V.)

At each voltage increment, the leakage current starts out higher than the
PS current limit, so the actual applied voltage doesn't rise to the PS
voltage setting immediately. As the oxide grows, the leakage current goes
down, so the voltage rises. Once it hits the PS voltage setting, the
voltage stays the same, but the leakage current continues to drop. I leave
it there until the leakage current stops declining (no further reforming
occurring), then go to the next voltage step.

With the few capacitors that wouldn't reform, at some voltage setting the
leakage current leveled off at a value higher than the maximum rated
leakage current. In some cases the leakage  current declined some but then
started to rise. When thag happens I conclude that thr capacitor has a
fault and cannot be reformed.

I usually use an lab supply that can be controlled over HP-IB or serial,
and use software to automate the process. The software sends a text message
to my phone when the process has completed or failed, and logs a fair bit
of information to a text file.