All is in the title.
An other very long shoot, isn't it ? ;-)
This is a (very ) long shoot !
I am looking for ( Fairchild ? ) CTL / CTuL 9956 chips.
Anyone ? Thanks.
I own a HP 1000 L series 200
Cards are badly corroded at connectors level BUT some other parts are in very
good shape.
I can offer,
HP "special SoS" processors: 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 )
The set of (3) Eprom
I cannot image them, but I am willing to send them to
On 2019-Feb-04, at 3:40 PM, Jack Harper via cctalk wrote:
>
> I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to a
> 19" rack.
>
> The screw holes that mate to the standard spaced holes on the right side of
> the drive after you open the case are visible and obvious.
>
>
On 2/4/19 3:40 PM, Jack Harper via cctalk wrote:
>
>
> Greetings to the List -
>
> I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to
> a 19" rack.
>
> The screw holes that mate to the standard spaced holes on the right side
> of the drive after you open the case are
I have a few of the limited function and programmers panels. I do not
recall either of them being dependent on particular backplane. I'll try to
pull a few a few later and check the part number on them.
Remember, a 54-X number can become a 70-X with the addition of a
cable or something
Yep, I noticed that, but thought it was a idea you might want to explore and
it’s simple enough to do.
Without the full output from the ls command and how it was executed I was just
throwing it out there.
For instance, was the default dir where ls was run, the same dir as when the
Greetings to the List -
I am mounting a couple of heavy (130-pounds each) HP7970e tape drives
to a 19" rack.
The screw holes that mate to the standard spaced holes on the right
side of the drive after you open the case are visible and obvious.
However, the holes on the left are hidden
Noel, it might be a wonky filesystem.
I’ve had ls -l seg fault because of bad attribute data on a file in a directory
on Solaris.
Interestingly, ls (without the -l) worked okay.
Maybe fsck or the equivalent command may show something.
It was a Solaris system with many concurrent users so I
On 02/04/2019 11:34 AM, Fritz Mueller via cctalk wrote:
2. Make a copy of ls, and see if the copy also fails
(different location on disk would mess with timing just a bit).
Also done; the copy appears to behave identically to the original.
OK, here's a really complicated thing to try.
On 02/04/2019 11:20 AM, Fritz Mueller via cctalk wrote:
The MMU classifies the error in register SR0; this decodes to a segment length
error (access within the segment beyond configured bound). As Noel notes,
however, this is not consistent with the instructions we see at the point of
eg: What is the structure of the "Header Case Information" block?
The E01 would be adequate (barely), if accompanied by an additional
"metadata" file that describes the physical format. (In much more
detail than just "IBM PC 360K", etc.) For MOST situations, OS,
encoding, bytes per sector,
And, of course, a lossy compression, such as MP4 leaves room for an
enormous amount of steganographic data, with documants and data hidden
in porn. (MANY different MP4 files will still play the same movie)
On Mon, 4 Feb 2019, John Foust via cctalk wrote:
That would be a very sneaky criminal
> From: Fritz Mueller
> I've had a bit of time in front of the machine to repro this and take a
> look. What I actually see is:
> R0 10
> R1 0
> R2 0
> R3 0
> R4 0
> R5 34
> R6 141774
> PC 000254
Argh. (Very red face!)
I worked out the trap stack
On 2/4/19 3:40 PM, Jim Manley via cctalk wrote:
> Did someone say "punched cards ... with steganographic bits in chads that
> are only attached along a couple of edges"?
NCR CRAM?
Did someone say "punched cards ... with steganographic bits in chads that
are only attached along a couple of edges"?
On Mon, Feb 4, 2019 at 4:36 PM Chuck Guzis via cctalk
wrote:
> On 2/4/19 3:22 PM, John Foust via cctalk wrote:
> > At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote:
> >> And,
On 2/4/19 3:22 PM, John Foust via cctalk wrote:
> At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote:
>> And, of course, a lossy compression, such as MP4 leaves room for an enormous
>> amount of steganographic data, with documants and data hidden in porn.
>> (MANY different MP4 files will still
On 2/4/19 2:49 PM, Fred Cisin via cctalk wrote:
> Well, conversion between E01 and IMD or teledisk formats looks
> straightforward.
>
> http://www.forensicsware.com/blog/e01-file-format.html
> Is there a better description handy?
>
> eg: What is the structure of the "Header Case Information"
>>> The obvious answer is bad memory.
>>
>> At the board level, yes. Deeper, it could be bad memory bits or bad
>> memory decode.
>
> Yes, one of the standard early PDP-11 memory tests is the "no duplicate
> address test".
I should say that the memory board is not _completely_ whack -- it
> On Feb 4, 2019, at 2:28 AM, Noel Chiappa via cctalk
> wrote:
>
> I'm pretty sure the command only gets a few instructions in before it blows
> up. Here are the process' registers, and the _entire_ contents of the user
> mode stack:
>
> R0 10
> R1 0
> R2 0
> R3 0
> R4 34
> R5 444
> SP
At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote:
>And, of course, a lossy compression, such as MP4 leaves room for an enormous
>amount of steganographic data, with documants and data hidden in porn. (MANY
>different MP4 files will still play the same movie)
That would be a very sneaky
> On Feb 4, 2019, at 5:47 PM, Ethan Dicks wrote:
>
> On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk
> wrote:
>>> On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk
>>> wrote:
>> That translates into "the problem depends on the physical address of the
>> code being executed".
>>
On Mon, 4 Feb 2019, Chuck Guzis via cctalk wrote:
Based on my conversations with clients, the problem is not the
equipment, but rather the lack of an open, vetted and documented file
format.
As an example, customers of mine insist on a "forensic" image file of
type E01 (Encase format), which
On Mon, Feb 4, 2019 at 3:15 PM Paul Koning via cctalk
wrote:
> > On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk
> > wrote:
> That translates into "the problem depends on the physical address of the code
> being executed".
>
> The obvious answer is bad memory.
At the board level, yes.
On 2/4/2019 11:34 AM, Fritz Mueller via cctech wrote:
>
>> On Feb 4, 2019, at 9:13 AM, Jay Jaeger wrote:
>>
>> If he hasn't already, if Fritz has more than one memory board, he might
>> try swapping them to see if that changes anything.
>
> I only have an 128kw MS11-L here to work with,
On 2/4/19 1:17 PM, Paul Koning wrote:
> Yes, but if the current format is wrong for the job, and people who should
> know better do not realize this, it would be a good idea (as a separate
> activity) to educate them and propose a better answer.
Yes, I know, and I've tried and written volumes
> On Feb 4, 2019, at 4:05 PM, Chuck Guzis via cctalk
> wrote:
>
> ...
> Based on my conversations with clients, the problem is not the
> equipment, but rather the lack of an open, vetted and documented file
> format.
>
> As an example, customers of mine insist on a "forensic" image file of
> On Feb 4, 2019, at 3:43 PM, Noel Chiappa via cctalk
> wrote:
>
>> From: Wayne S
>
>> it might be a wonky filesystem. ...
>> The corruption probably came because the entire disk was going bad.
>
> This theory is contradicted by the fact (mentioned several times, including in
> the message
On 1/18/19 7:40 AM, geneb via cctalk wrote:
> This looks like a project with a ton of potential for archviving media
> without having to deal with the asshattery of the kryoflux people.
>
> https://github.com/picosonic/bbc-fdc
Yes, you can do this, as I've said many times before, with just about
> From: Wayne S
> it might be a wonky filesystem. ...
> The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300
> Date: Sun, 3 Feb 2019 22:22:42 +0100
> From: Pontus Pihlgren
> To: "General Discussion: On-Topic and Off-Topic Posts"
>
> Subject: Looking for Limited Function Board
> Message-ID: <20190203212242.gf24...@update.uu.se>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> I'm restoring
> From: Jay Jaeger
> This sort of situation, where DEC diagnostics run OK but UNIX has issues
> was reported to be not all that uncommon - to the point where the urban
> legend was that some DEC FE's would fire up Unix V6 as a sort of system
> exerciser.
Amusing! Never heard
On Mon, Feb 4, 2019 at 11:35 AM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:
> The spec says allowed tolerances are +/- 5%. He knew the reality for
> correct operation was -0%, +5%, so he tweaked all the supplies to read a
> hair above nominal.
>
Ah, the good old days... I recall
> On Feb 4, 2019, at 10:34 AM, Paul Koning via cctalk
> wrote:
>
>> On Feb 4, 2019, at 12:18 PM, Bob Smith via cctalk
>> wrote:
>>
>> I keep wondering about the psu.
>
> Good theory.
I'll give these a double-check...
> Is there any way to attach a logic analyzer to various data paths on
> On Feb 4, 2019, at 12:18 PM, Bob Smith via cctalk
> wrote:
>
> I keep wondering about the psu. I just recall the /45 in my lab was
> always a little flakey.
> We suspected everything in the machine, and it was ak to chasing a sea
> bat in the dark.
Good theory.
In RSTS development we
> From: Jon Elson
> Does the MMU classify what the error condition was
Yes, there are a series of bits in SSR0 to indicate the particular error:
'non-resident', 'length', 'read-only', etc (and also the segment number the
error's from). As my message mentioned, we're seeing the 'length'
> On Feb 4, 2019, at 9:13 AM, Jay Jaeger wrote:
>
> If he hasn't already, if Fritz has more than one memory board, he might
> try swapping them to see if that changes anything.
I only have an 128kw MS11-L here to work with, unfortunately. Its been through
a bunch of recent troubleshooting
Hi all; thanks for the write-up on the issue, Noel!
> On Feb 4, 2019, at 8:24 AM, Jon Elson via cctalk
> wrote:
> Is this truly a fault given by the memory management system, or some other
> kind of fault (Unibus timeout or memory parity error)?
Trap 250, which is explicitly memory
I keep wondering about the psu. I just recall the /45 in my lab was
always a little flakey.
We suspected everything in the machine, and it was ak to chasing a sea
bat in the dark.
Our environment in ML 1-2 was not the best, the floor actually moved,
we were right at the mid building elevator.
We
On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote:
> On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote:
>>
>> First oddity - the problem is dependent on the location of the command
>> in main
>> memory! If Fritz says "sleep 360 &", to run a trivial command in the
>> background, and _then_ says
On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote:
So I've been helping Fritz look into his -11/45 problem, and things have
gotten to a point where I'd like to reach out for help, more eyes, etc.
OH, does this machine have a cache? We had a /45, and got a
cache module for it. It
On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote:
First oddity - the problem is dependent on the location of the command in main
memory! If Fritz says "sleep 360 &", to run a trivial command in the
background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on
disk is OK)!
So I've been helping Fritz look into his -11/45 problem, and things have
gotten to a point where I'd like to reach out for help, more eyes, etc.
I have to say, I spent almost a decade at the start of my career working on
PDP-11 hardware ('new build' DMA devices, as well as fixing broken stuff),
43 matches
Mail list logo
