Hey guys-
Anyone on here know much about the Marvel boxes? I've had one for years but never had much time to fiddle with it. I'm looking at the partitioning features. In particular, the manual says:
Hard partitions must be on 2P boundaries
Tru64 only supports hard partitions
However, I can confirm that you can definitely create a hard partition with a single CPU. This got me thinking, and I dug a little deeper into the MBM CLI. The manual seems to suggest that this is the case, but says that the operating system won't work correctly in that configuration. Anyone know why not?
When you create a hard partition, you specify what type of subpartition the hard partition can contain. The manual says that only "soft" partitions are officially supported, but the CLI also allows you to create subpartitions of type "firm" and "semi-firm". Does anyone know what "firm" and "semi-firm" partitions do differently than soft partitions? And does Tru64 work with any of that, or is all of that OpenVMS-specific stuff?
Also, on a side note, I don't suppose anyone here has a rail kit for an ES47 or ES80 they'd like to sell, or an I/O drawer...
Many thanks in advance!
-Ben
I have a Cisco IGS router which hasn't worked for a long time. When I was
last using it several years ago, it occasionally crashed and restarted.
This turned out to be due to a poor contact on a connection in the
cable going from the output of the power supply to the main board. I
cleaned the contact more than once but it was difficult to make it good
enough to ensure reliability.
When I switched it on more recently, it was completely dead, no LEDs, no fan
noise, no anything. I put it in the naughty pile and it sat there for a few
years before I got around to looking at it.
Today I finally managed to check it out. The ceramic F4A mains input fuse
beside the power switch on the back panel had blown. When I opened it up,
I found a POWER-ONE MAP80-4000 power supply. The main chopper transistor
labelled Q1 on the PCB is almost a dead short. It is a large plastic
packaged FET mounted on a piece of aluminium which is in turn screwed to
the case for heatsinking. Unfortunately, there are no markings on it so
I have no idea what to replace it with :-(
As Q1 is shorted across all three terminals, whatever drives it may be
damaged too :-(
After finding screw heads hidden under the label, I managed to extract
the PCB from the case and found some corrosion underneath, possibly from
leaking electrolytic capacitors :-(
There are lots of data sheets available for this power supply on the web
but they concentrate on the specifications for the unit and don't say
anything about the components :-(
There are also lots of people offering to sell power supplies like this
for way more than I am interested in spending on this project :-(
I could replace the power supply with a different one, however, I don't
have anything to hand that will fit in the approx 5-6cm headroom :-(
Anyone have any suggestions?
Regards,
Peter Coghlan.
Between the 30th of March and the 20th of April.
I am a computer collector from England and specialise on computer artefacts
>from the 1940s to the 1970s. and would love to attend one of these when
visiting my son in TN.
Many thanks,
peter vp
I've got a piece of gear here with a bad MC858P used as a bus
driver--terminated in 220/330 ohms at the far end.
Given that old DTL is a hit-or-miss proposition, I'm proposing to
substitute a 7438 OC buffer. Pinout's the same, as is Vcc.
Before I get out the soldering iron, any "don't do it" thoughts?
--Chuck
Hi,
I have 4 pcs. IDT49C402 Bit Slices, it is no problem to find a datasheet
for that chip..but it is an problem to find the pinout for the PGA84
Package. In all Datasheets that I've found only DIP68, LCC/PLCC68
PGA68 and CERQUAD68 are listet..
Has anyone a databook newer than 1989 where the PGA84 Pinout is listed?
TIA,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583
info at tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741
> From: Warner Losh
> Do those chips have ROM numbers on them?
I have updated the:
https://gunkies.org/wiki/KD11-E_CPUhttps://gunkies.org/wiki/KD11-EA_CPU
articles with the DEC part numbers for the i) microcode and ii) instruction
decode PROms.
That's not all the PROMs on the Control card - there are effing bazillions of
the damned things (I suspect they used them to reduce the amount of random
logic, so the CPU'd fit on two boards) - but it's most of them.
I have yet to triple-check them, so there might still be transcription error
or two.
> From: Rod Smallwood
> I am sure somebody will come up with the actual images either the
> original files or derived from what we have.
I wouldn't be too sure of that; silence so far. I have reached out to Mike
Douglas, to ask where the microcode dump on DeRamp came from: perhaps the
originator can help with the missing bits. (Although perhaps I should ask Al
K; BitSavers also has the dump, and it's older, so perhaps that copy came
>from the originator.)
> We have narrowed the problem down.
> Its the instruction decode ROM's that are the issue.
> The images of those are whats needed.
All of them? Or is just one failed?
I'm wondering if you've just had a single one lose a bit or two; that's
somewhat common in old PROMs. The chip you reported as failing (E111) almost
certainly couldn't have taken out an instruction decode PROM, it's nowhere
near them.
I ask because we have absolutely nothing on those PROM's contents. With the
microcode PROMs, we at least have the contents in symbolic form (see pg. 15
of MP00082; alas, we don't seem to have the KD11-EA equivalent of Table 7-15
>from EK-FP11A-TM-002), but for all the instruction decode PROMs - nada.
Absolutely nothing.
But if they're _mostly_ there, with the partial contents, and a description
of the failure mode (e.g. 'SETC doesn't set the C bit'), we might be able to
work out what bit got dropped.
Failing that, someone's going to have to volunteer to unsolder a set, and
read them out - at least, I assume that's what would have to be done. Perhaps
a logic analyzer could be attached to an instruction decode ROMwhile the CPU
ran diagnostics, and eventually a complete readout of the contents
accumulated.
Noel
>>> On Tue, Feb 8, 2022 at 6:18 PM Rod Smallwood wrote:
>>> On the M8266 CPU control board a defective 7404 (E111) has killed a
>>> bunch of the PROMs holding the microcode.
That's pretty astonishing; I've heard of PROMs dropping bits over time, but
I'm a bit amazed to hear of a failure in a TTL gate (the 74S04 is a hex
inverter; its gates are on pg. 7 of the M8266 prints - they produce uPC03-08)
taking out a bunch of other gates connected to it.
>> On Tue, Feb 8, 2022 at 7:04 PM Warner Losh <imp at bsdimp.com> wrote:
>> I found
>> https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporat…
>> which has the source code...
>>
>> But I couldn't find the tools to use these files to create microcode
>> images.
Actually, the "m8266_ucode.v.txt" there seems to actually be the program that
produced the symbolic dump (which is also available at:
http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt)
It looks like the program is in VHDL or something like that, but it doesn't
seem to have the actual microcode (was it stored/defined in another VHDL
file?); that raises the question of where the actual microcode that it was
dumping was.
It might be worth inquiring of Mike Douglas (he runs the DeRamp site) to find
out where the files in "mfe_archive" came from; perhaps the source has, or
knows of, the file which "m8266_ucode.out.txt" was a symbolic dump of - maybe
>from a complete KD11-EA simulation in VHDL?
If that's not possible,it would be trivial to extract the PROM contents
(well, partial contents - see below) from the "m8266_ucode.out.txt" file;
each uword entry starts with the lines:
***** PDP-11/34a micro code word for MPC = 000 *****
(MSB is left, indented fields generated by expansion ROMs)
micro word........ = 0000 0111 1100 0000 1100 1000 1010 0001 0000 0000 1110 0000
from ROM: E105 E103 E104 E100 E98 E97 E99 E106 E107 E108 E109 E110
The address of each uword is the "MPC = xxx" line; the contents of the 12
PROMs, at that address, are given on the "micro word........ = " line (the
PROMs are 4 bits wide).
If someone explained what format they needed as input for burning new PROMs,
I could easily (like an hour) write a small portable program (using StdIO
only, so it could be compiled and run on _anything_) that read that file in,
and spat out the 12 PROM files. (Most of the dump could be ignored - all the
data that's needed is in that one line.)
BUT (and this is why it would be good to get back to the source of that file),
that's not a complete M8266 ucode PROM dump.
The KD11-EA has a uword address space 1 bit larger than the KD11-E - almost
certainly to support floating point instructions; the KD11-EA adds 'uPC 09'
(although looking its source at the top of pg. 7 of the prints, I don't quite
grok how it is generated - maybe it's fed back through J2 from the FP11-A when
one is plugged in). Anyway, uword addresses run up to 02000 in the KD11-EA,
and the last uword in that dump is 0777.
Interestingly, according to the flow charts of the 'basic' KD11-E/EA ucode in
the prints (indexed and annotated here:
https://gunkies.org/wiki/KD11-E/EA_microcode
in full), they stop at 0757 - but the dump (in "m8266_ucode.out.txt")
contains uwords that are 'supposed' to be blank (per the flow charts),
as well as above 0757.
So that dump must have been prepared from a copy of the 'new' KD11-EA PROMs -
the ones including the floating point ucode. (Note that the FP11-A _also_
contains ucode, intended to control the stuff on the FP11-A; but the floating
point instructions _also_ use the KD11-A for some stuff - e.g. fetching
operands from main memory. Only the ucode address space is shared.)
> From: Warner Losh
> There's a small chance that the tools.tar.gz link on
> http://www.ak6dn.com/PDP-11/M9312/ has these, but that's for a
> different module so who knows.
Right, a _completely_ different card - a boot PROM, not a CPU; totally
un-related - and by a different person (Don North).
But just for completeness, I looked in "tools.tar.gz", and it's just
bootstrap PROM stuff.
Noel
You may recall that, a few weeks ago, I requested parts help (shopping
baskets) for
the Retro Chip Tester Pro that I got for Christmas. Well, today's mail
brought the last
few parts and I have finished and tested it. Wow! The only thing that it
doesn't do is
slice bread. It's great. I've put up a few pictures here:
http://wsudbrink.dyndns.org:8080/images/RCTPro/
I got the 4008 and 1702 adapters with it, but I'm pretty sure that I will
get the rest over
the next month or so. This is the latest HW version with the latest release
software.
Bill S.
PS: Thanks to everyone that helped with parts.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> So it sermsdectape heads are special. I don?t think Dec would have the desire to make them internally so they probably contractef with a company already set up to do that. Who were the big tape head manufacturers at that time? Does anyone know?
A photo of the back of a TU56 DECtape head can be seen at https://www.pdp8online.com/tu56/pics/head_label.shtml?small .
The head has a label on it that reads:
Western Magnetics
Glendale Calif.
Record
7282
I've never seen a TU56 in person and have no idea if they have separate read, write, and erase heads or some other combo. The "Record" notation on the above head's label hints to me this might be a write head.
I found that and other DECtape photos at https://www.pdp8online.com/tu56/tu56.shtml .
-- Ron
