On Tue, 19 Feb 2019 at 22:00, Fred Cisin via cctalk
wrote:
>
> Yes.
> I was thinking in terms of slightly older drives than that, particularly
> 5.25"
> Getting at the slider on newer drives wouldn't be practical.
Probably not. I suspect that ITRO 90+ % of the people I work with have
never seen a
One of the moxt common causes of a terrible ear-piercing high whine is the
spindle contact. Many old drives had a springy piece that rubbed against
the end of the spindle. Over time, it would wear a divot, polish that,
and start to squeal. A very light pressure on it would test that
hypothesis.
On Mon, 18 Feb 2019 at 22:16, Fred Cisin via cctalk
wrote:
>
> One of the moxt common causes of a terrible ear-piercing high whine is the
> spindle contact. Many old drives had a springy piece that rubbed against
> the end of the spindle. Over time, it would wear a divot, polish that,
> and star
> On Feb 18, 2019, at 4:47 PM, Jay Jaeger via cctalk
> wrote:
>
> On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote:
>>
>> ...
>> Then again, I remember our college RS64 (drive for the RC11) which developed
>> a bad motor bearing. ...
>>
>
> Nice of the FE to do that.
>
> The Univ. of
On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote:
>
>
>> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk
>> wrote:
>>
>> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
>>> Well that is the thing, of course. I had that with one old IDE disk,
>>> too. It made a terrible ear-piercing high
> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk
> wrote:
>
> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
>> Well that is the thing, of course. I had that with one old IDE disk,
>> too. It made a terrible ear-piercing high whine that I associate with
>> a failing disk... but it pas
On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
Well that is the thing, of course. I had that with one old IDE disk,
too. It made a terrible ear-piercing high whine that I associate with
a failing disk... but it passed every diagnostic I could throw at it,
so I used it for non-critical stuff a
On Sat, 16 Feb 2019 at 01:43, Peter Coghlan via cctalk
wrote:
> Days turned into weeks, weeks into months and months into
> years. It continued to occasionally make the same ghastly noises that
> never should be heard coming from a hard disk but with absolutely no sign
> of any errors being log
Liam Proven wrote:
>
> And some of my younger colleagues thought it was strange that I could
> predict hard disk failures from the running noises they made, and
> later than that, whether WinNT's bus-mastering DMA-mode disk
> controller device driver was installed from the sound of the disk
> acce
Jeffrey S. Worley wrote:
>
> Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be
> able to run the snazzy AOS/VS II tapes I'd got along with the 9 track
> drive I hacked onto the machine...
>
> The install would start and then bomb at a certain point every time. I
> decided to w
> From: Paul Koning
> Studied it for a while, took out a small hammer, whacked the device at
> some spot, and reported "fixed".
That reminds me of an amusing story from the first time I went to see 'Star
Wars; I went with a group of people from Tech Sq. It has that scene where
they're
On Fri, 15 Feb 2019 at 14:59, Paul Koning wrote:
>
> Speaking of sounds made by machines, there is a famous security paper from a
> few years ago in which researchers read the encryption keys out of
> smartphones by listening to the sounds made by the device while it was
> execution the crypto
> On Feb 15, 2019, at 6:06 AM, Liam Proven via cctalk
> wrote:
>
> On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk
> wrote:
>>
>> The install would start and then bomb at a certain point every time. I
>> decided to work the machine hard and then pull the board and give a
>> good
Fritz Mueller wrote:
>
> That's right -- I wasn't without an army, it was just a very small and
> quite dedicated army! :-)
>
> I think I'd have gone down many blind alleys without help and perspective
> provided by others here, and in particular a lot guidance provided by Noel
> over the past co
On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk
wrote:
>
> The install would start and then bomb at a certain point every time. I
> decided to work the machine hard and then pull the board and give a
> good SNIFF.
Got a nose for a hardware fault, eh? ;-)
And some of my younger collea
> Message: 2
> Date: Wed, 13 Feb 2019 15:03:41 -0500
> From: Paul Koning
> To: Jay Jaeger , "General Discussion: On-Topic and
> Off-Topic Posts"
> Subject: Re: PDP-11/45 RSTS/E boot problem
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
&
guys come off with a win.
I really enjoy reading this list even though I don't contribute all
that often or anything of much value. It is a pleasure to watch you
guys work.
Jeff
On Thu, 2019-02-14 at 12:00 -0600, cctalk-requ...@classiccmp.org wrote:
> Re: PDP-11/45 RSTS/E boot problem
That's right -- I wasn't without an army, it was just a very small and quite
dedicated army! :-)
I think I'd have gone down many blind alleys without help and perspective
provided by others here, and in particular a lot guidance provided by Noel over
the past couple weeks in private corresponde
> From: Paul Koning
> or a backup team of subsystem experts at the home office to call on.
Actually, the actual hardware problem wasn't too hard for Fritz to find, I
gather, once we knew exactly was failing (the RK11), and how (at 017, the
XM incremented). It's not like it was a comes
Ethan Dicks wrote:
> I have had an RK11-C for a long time that I've never tried to
> power up (I got an RKV11-D and used that on Qbus machines
> instead).
Wow, someone else with an RKV11-D! I thought I was the only
person who had one. I modified mine (using the dead bug
technique) to add 18-b
> From: Jerry Weiss
> I am trying to understand how the diagnostics didn't reveal this defect.
Vondada #12: "Diagnostics are highly efficient in finding solved problems." :-)
Noel
[oops, accidentally replied directly instead of to the list]
On 2/13/19 12:54 PM, Ethan Dicks wrote:
> It's interesting that it was a bad 7430 in [your RK11-C]. I find that for
> equipment of that vintage, my usual suspects are failed 7474s and failed
> 7440s, probably 80% of the total. Behind
On 2/13/19 5:20 PM, Jerry Weiss wrote:
I am trying to understand how the diagnostics didn't reveal this
defect. I see in the source for the diagnostic DZRKH-F there are tests
for address in the 28K-32K range and also for the 32K boundary.
So, to catch this defect the diagnostic would have to
On 02/13/2019 10:40 AM, Noel Chiappa via cctalk wrote:
He's also had to do a tremendous amount of work on it to get it running,
starting with building an entire new power harness.
Yes, the 5V power harness between the regulators and the
backplane were a real mess on the 11/45 we got second hand.
On 2/13/19 1:43 AM, Fritz Mueller via cctalk wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around
with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled,
socketed, replaced, and off she goes!
I can now successfully boot and run b
> On Feb 13, 2019, at 3:03 PM, Paul Koning wrote:
>
> ...
> My suspicion is that things not solved by diagnostics would be escalated to
> the "wizard from Maynard". And they'd probably start replacing whole
> subsystems.
This says that Fritz actually was a new "Wizard from Maynard" in sol
> On Feb 13, 2019, at 3:54 PM, Ethan Dicks via cctalk
> wrote:
>
> ...
> It's interesting that it was a bad 7430 in yours. I find that for
> equipment of that vintage, my usual suspects are failed 7474s and
> failed 7440s, probably 80% of the total. Behind that, it goes 7420s
> and then may
On Wed, Feb 13, 2019 at 2:43 AM Fritz Mueller via cctalk
wrote:
>
> SUCCESS!!
Outstanding!
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look
> around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND).
> Pulled, socketed, replaced, and off she goes!
>
>
> On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk
> wrote:
>
> ...
> Maybe that story about FE's using Unix as a test to confirm operation
> even when diagnostics said the machine was OK was not so much just a
> legend?
It still fels like a legend. My experience with DEC field service eng
On 2/13/2019 1:43 AM, Fritz Mueller via cctalk wrote:
> SUCCESS!!
>
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look
> around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND).
> Pulled, socketed, replaced, and off she goes!
>
> I can now successfull
> From: Alan Frisbie
> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.
I forgot to mention the most amazing part of the whole story: he first
acquired the machine while he was a student (I think?) at CMU,
On 02/13/2019 01:43 AM, Fritz Mueller via cctalk wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around
with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled,
socketed, replaced, and off she goes!
WOW! Good detective work, that
> From: Alan Frisbie
> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.
:-)
> The ideas, hunches, tests, dead ends, and results are an excellent
> example of the debugging process.
Yeah, and it wa
> On Feb 13, 2019, at 2:43 AM, Fritz Mueller via cctalk
> wrote:
>
> SUCCESS!!
>
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look
> around with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND).
> Pulled, socketed, replaced, and off she goes!
>
> I ca
SUCCESS!!
Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around
with a logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled,
socketed, replaced, and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
*THAT* was a r
> > > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
> >
> > No; the RK11 spec says "[the two extended memory bits] make up a two-bit
> > counter that increments each time the RKBA overflows".
> >
> > The actual error turns out to be slightly different to my guess; there'
> From: Jerry Weiss
> it is impressive that UNIX booted successfully without tripping over a
> boundary.
Well, V6 is (or can be configured to be) extraordinarily small, so I'm not
surprised it booted OK without going over the 017 mark.
I have this persistent memory that the -11/4
On 2/11/19 12:31 PM, Noel Chiappa via cctalk wrote:
> From: Jerry Weiss
> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
> boundaries.
Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
from the RC11 controller, and that _can_
> From: Jerry Weiss
> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
> boundaries.
Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
from the RC11 controller, and that _can_ cross moby boundaries, so clearly it
has the right overfl
> On Feb 11, 2019, at 1:13 PM, Jerry Weiss wrote:
>
> On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:
>>> ...
>> You may be thinking about PC controllers like the floppy controller. I
>> can't remember ANY DEC DMA device controller that had boundary crossing
>> limits of any kind. It ce
On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:
On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk
wrote:
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a mul
Yup; specifically, the symptoms are consistent with 'D15 RKBA=ALL 1 L' being
incorrectly generated at BA 16, causing an increment to EX.MEM, causing a
skip in the DMA.
So it looks like problem with bit 12 in that carry logic; I'll check E28 and
E34 when I get back to it tonight, but I have
On Mon, Feb 11, 2019 at 6:03 PM Noel Chiappa via cctalk
wrote:
>
> > From: Jon Elson
>
> > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
>
> No; the RK11 spec says "[the two extended memory bits] make up a two-bit
> counter that increments each time the RKBA overflo
> From: Jon Elson
> Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
No; the RK11 spec says "[the two extended memory bits] make up a two-bit
counter that increments each time the RKBA overflows".
The actual error turns out to be slightly different to my guess; there
> On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk
> wrote:
>
> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
>> A look at the RK11 registers after the swap-out showed an anomaly; something
>> about the extended memory address bits? (Maybe a multi-block transfer than
>> crosses a 6
On Mon, Feb 11, 2019 at 4:13 PM Jon Elson via cctalk
wrote:
>
> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
> > A look at the RK11 registers after the swap-out showed an anomaly; something
> > about the extended memory address bits? (Maybe a multi-block transfer than
> > crosses a 64KB
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopef
> From: Fritz Mueller
> If, as you are suspecting, we find damning evidence pointing
> specifically to the RK11
I got an update from Fritz. As you all will recall, the problem seemed to be
a corrupted 'pure text'. So the question was 'when was it damaged, and how'.
After some confusi
>> This seems the best place to start with the LA this weekend then.
>
> I'm going to respectfully semi-disagree! I think that at this point there's a
> good chance we can localize to within a gate or two before we start applying
> test instruments.
Oh, I agree completely, Noel. I should have
> From: Fritz Mueller
> This seems the best place to start with the LA this weekend then.
I'm going to respectfully semi-disagree! I think that at this point there's a
good chance we can localize to within a gate or two before we start applying
test instuments.
My thinking starts with tw
>>> How about a Unibus trace?
>>
>> I don't think my sad little HP LA has enough buffer for that...
>
> You could use triggers in innovative ways.
Ah, quite right, gentlemen. This seems the best place to start with the LA
this weekend then.
--FritzM.
On 2/7/2019 11:47 AM, Noel Chiappa via cctalk wrote:
>
> The interesting point is that when V6 first copies the text in from the file
> holding the command (using readi(), Lions 6221 for anyone who's masochistic
> enough to try and actually follow this :-), it reads it in starting from the
> bo
torsdag 7 februari 2019 skrev Fritz Mueller via cctalk <
cctalk@classiccmp.org>:
>
> > How about a Unibus trace? That would give you the RK11 commands as well
> as the data it sends in response.
>
> I don't think my sad little HP LA has enough buffer for that...
You could use triggers in innova
> How about a Unibus trace? That would give you the RK11 commands as well as
> the data it sends in response.
I don't think my sad little HP LA has enough buffer for that...
--FritzM.
> On Feb 7, 2019, at 1:37 PM, Fritz Mueller via cctalk
> wrote:
>
>
>> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk
>> wrote:
>>
>> So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
>> I think. And it wound up at PA:171600 - off by 04000 (higher) - which
> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk
> wrote:
>
> So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
> I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
> obviously an interesting number.
Thanks, Noel.
> ...it might be intere
> From: Fritz Mueller
> is it possible for you deduce where Unix _should_ be placing these "bad"
> bits (from file offset octal 4220)?
Yes, it's quite simple: just add the virtual address in the code to the
physical address of the bottom of the text segment (given in UISA0). The VA
is
On 02/06/2019 09:11 PM, Noel Chiappa via cctalk wrote:
> From: Jon Elson
> I'm thinking it is bad memory. ... I think it is just a bad memory chip
Nothing so simple, I'm afraid! The memory actually contains:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
and i
> Seems a little less-likely to be the problem, given(?) as well that you have
> fairly consistent (is deterministic overstating it?) behaviour.
Yeah. We've gotten to the point now where enough layered problems have been
cleared away that the remaining behavior is quite deterministic.
> If you
On 2019-Feb-06, at 10:37 PM, Fritz Mueller via cctalk wrote:
>> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the
>> 14.5uS from the manual would give 1.86 mS, 7% shy of 2.
>> The schematic specs 1% resistors, and the parts list does appear to spec a
>> high-tolerance "1%200
> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS
> from the manual would give 1.86 mS, 7% shy of 2.
> The schematic specs 1% resistors, and the parts list does appear to spec a
> high-tolerance "1%200PPM" cap.
>
> Although there are the internal voltage divider Rs
It looks like the question boils down to either "how did that part of
the binary get to that part of memory?", or "how did we end up
executing out of that part of memory?"
More the former, I think...
Noel, is it possible for you deduce where Unix _should_ be placing these
"bad" bits (from
> From: Fritz Mueller
> It looks like the question boils down to either "how did that part of
> the binary get to that part of memory?", or "how did we end up
> executing out of that part of memory?"
More the former, I think.
UISA0 contains 001614, and physical memory at 0161400
> From: Jon Elson
> I'm thinking it is bad memory. ... I think it is just a bad memory chip
Nothing so simple, I'm afraid! The memory actually contains:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
and it's _supposed_ to be holding:
PA:171600: 110024 010400 00
On 2/6/19 6:25 PM, Jon Elson via cctalk wrote:
I'm thinking it is bad memory. It seems unlikely bus problems could
alter only ONE BIT per word, so I think it is just a bad memory chip,
and finding multiple words where the 01 bit is now turned on sure
looks like that kind of problem.
So
On 02/06/2019 05:39 PM, Fritz Mueller via cctalk wrote:
On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
wrote:
Is the schematic available for the memory board at-issue?
Curious myself to see what approach for refresh DEC used.
Yes, here:
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/
On 02/06/2019 04:24 PM, Brent Hilpert via cctalk wrote:
On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote:
From: Brent Hilpert
what about the refresh circuitry of the memory board?
...
It might also explain why a number of 4116s were (apparently) failing
earlier in the efforts ... replac
On 02/06/2019 12:53 PM, Noel Chiappa via cctalk wrote:
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news).
I'm thinking it is bad memory. It seems unlikely bus
problems could alter only ONE BIT per word
On 2019-Feb-06, at 5:29 PM, Paul Koning wrote:
>> On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk
>> wrote:
>> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
> wrote:
>
> Is the schematic available for the
On 2019-Feb-06, at 3:39 PM, Fritz Mueller wrote:
>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
>> wrote:
>>
>> Is the schematic available for the memory board at-issue?
>> Curious myself to see what approach for refresh DEC used.
>
> Yes, here:
> http://bitsavers.trailing-edge.com/pd
> On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk
> wrote:
>
> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
wrote:
Is the schematic available for the memory board at-issue?
Curious myself to s
On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
>>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
>>> wrote:
>>>
>>> Is the schematic available for the memory board at-issue?
>>> Curious myself to see what approach for refresh DEC used.
>>
>> Yes, here:
>> http://bitsavers.t
>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
>> wrote:
>>
>> Is the schematic available for the memory board at-issue?
>> Curious myself to see what approach for refresh DEC used.
>
> Yes, here:
> http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
Fo
> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk
> wrote:
>
> Is the schematic available for the memory board at-issue?
> Curious myself to see what approach for refresh DEC used.
Yes, here:
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
There is also
On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote:
>> From: Brent Hilpert
>
>> what about the refresh circuitry of the memory board?
>> ...
>> It might also explain why a number of 4116s were (apparently) failing
>> earlier in the efforts ... replacing them might have just replaced them
>>
> From: Brent Hilpert
> what about the refresh circuitry of the memory board?
> ...
> It might also explain why a number of 4116s were (apparently) failing
> earlier in the efforts ... replacing them might have just replaced them
> with 'slightly better' chips, i.e. with a
On 2019-Feb-06, at 10:53 AM, Noel Chiappa via cctalk wrote:
>
> I'm not sure that's going to tell us much: the latest development is that
> Fritz looked at the actual memory contents again, and it is once again
> trash; _almost_ identical to what was there before:
>
> PA:171600: 016162 004767 00
> From: Mattis Lind
>> we've also looked at what's in memory at that location, and the low
>> part of the text segment seems to be correct, but there was junk at
>> the top, around the target of the JSR (i.e. at 'csv'). Not just one
>> word, but everything around that location
> On the logic analyzer suggestion: I remember seeing a logic analyzer hooked
> to a PDP-11 at DEC, for software debugging. As I recall, it was connected at
> the console front panel, which seems reasonable since several key CPU data
> paths are exposed there.
Ooh, I like that suggestion! It
>> Would it be any difference if you run the machine at full speed or lower
>> speed...
>
> Ah, yes -- this I haven't tried yet! I have a KM11 replica, so this is easy
> enough to do; I'll give that a go when I next get back to the machine
> (possibly this evening).
Ran the machine on the mai
On the logic analyzer suggestion: I remember seeing a logic analyzer hooked to
a PDP-11 at DEC, for software debugging. As I recall, it was connected at the
console front panel, which seems reasonable since several key CPU data paths
are exposed there.
paul
On Tue, Feb 5, 2019 at 10:03 AM Fritz Mueller via cctalk <
cctalk@classiccmp.org> wrote:
>
>
> FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of
> running PDP11GUI, and I use an USA19H USB serial dongle connected through
> to the VM as a serial interface. I don't know if s
On 2/5/2019 12:03 PM, Fritz Mueller via cctalk wrote:
>> Perhaps compile [test programs] under SimH and do a block-level diff of the
>> image with what is currently in use, and transfer just those blocks?
>
> I did experiment with this a little way back. I wrote a small standalone
> code that d
> On Feb 5, 2019, at 10:03 AM, Fritz Mueller wrote:
>
> Unfortunately, when I tried to apply this, it seemed that SIMH's write single
> sector wasn't working correctly for me...
Correction to above: "PDP11GUI's write single sector". Apologies!
--FritzM.
> Would it be any difference if you run the machine at full speed or lower
> speed...
Ah, yes -- this I haven't tried yet! I have a KM11 replica, so this is easy
enough to do; I'll give that a go when I next get back to the machine (possibly
this evening).
> ...or even single step past this
>>> I keep wondering about the psu.
>>
>> Good theory.
>
> I'll give these a double-check...
I did give these a look yesterday. Indeed, the +5 regulator in position "C"
(which includes supply to the KT11) was running a little low (4.9 and change).
I trimmed it up, and checked the rest of t
> On Feb 5, 2019, at 8:45 AM, Jon Elson via cctalk
> wrote:
>
> I'd guess the diagnostic tries a few patterns to test for gross failure of
> this circuitry, but since it involves memory on a system running a program,
> it may not be able to exhaustively test these adders and comparators.
In
> Perhaps compile [test programs] under SimH and do a block-level diff of the
> image with what is currently in use, and transfer just those blocks?
I did experiment with this a little way back. I wrote a small standalone code
that dumps a CRC of every sector over the console; I can run this bo
On 02/05/2019 07:36 AM, Noel Chiappa via cctalk wrote:
One would hope that the DEC KT11 diagnostic would check for this... but just
to be thorough, we have in fact written a short diagnostic which stores every
possible value in each UISA register and checks that it's correct. So unless
there is s
Den tis 5 feb. 2019 kl 00:23 skrev Fritz Mueller via cctalk <
cctalk@classiccmp.org>:
>
> > On Feb 4, 2019, at 2:28 AM, Noel Chiappa via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > I'm pretty sure the command only gets a few instructions in before it
> blows
> > up. Here are the process' reg
>
> Yeah, it may come to that. One issue we've been having is doing specialized
> test programmes; trying to run the C compiler fails. I don't know about the
> assembler, though. And as Fritz mentioned, it takes hours to load a new disk
> image. I think we've come up with a way around that, though
> From: Paul Koning
> Another possibility occurs to me: bad bits in the MMU (UISAR0 register
> ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly
> you'd expect to come up with execution that looks nothing at all like
> what was intended.
One would hope that th
Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Noel Chiappa
Sent: Monday, February 4, 2019 12:43:09 PM
To: cctalk@classiccmp.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: PDP-11/45 RSTS/E boot problem
> From: Wayne S
&
Cc: j...@mercury.lcs.mit.edu
Subject: Re: PDP-11/45 RSTS/E boot problem
> 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 w
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
fault.
> 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
>>> 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 is
> 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 1
> 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".
>>
>>
1 - 100 of 201 matches
Mail list logo
