Re: DEC KA650 VAX memory troubleshooting

[Joseph Zatarski via cctalk]

Well, I finally got around to posting this on the CHWiki, in case 
anybody was curious about this.


https://gunkies.org/wiki/DEC_KA650_Memory_Subsystem

On 6/17/19 7:56 PM, Joe Zatarski wrote:

OK, so where should a thing like this go: https://pastebin.com/taQwaTV6

Anybody got a decent place to upload that? it's my notes on the 
MS650-AA, and more generally the KA650 CMCTL memory subsystem.


Includes my theory of operation of the CMCTL, the organization of 
memory, the ECC equations (kinda, the info is there to derive them), 
explanations of the signals on the memory bus, and most importantly, a 
list of which bits and RAM regions correspond to the 312 DRAMs on the board.


On Sat, Jun 15, 2019 at 8:33 PM Joe Zatarski > wrote:

 >
 > Hey Everyone,
 >
 > I just thought I'd share a video of how I'm going about 
troubleshooting the bad DRAMs on my MS650 memory board.

 >
 > https://youtu.be/eDMhdAEFEgc
 >
 > I apologize for the shaky-cam, I don't have a tripod, and I needed to 
do a lot of panning anyway.

 >
 > I will be sharing my notes on the MS650 once I have a chance to write 
them up properly as well. I wasn't able to find a printset for the RAM 
card itself, so I assume one doesn't exist in digital form yet. I have 
documented what bit and memory range each DRAM on the card corresponds 
to, which may help someone troubleshooting in the future

 >
 > Regards,
 > Joe Zatarski

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Noel Chiappa via cctalk]

> From: Rob Doyle

> http://www.bitsavers.org/pdf/dec/unibus/RH11-C_Engineering_Drawings.pdf

Oooh, thanks ever so much. Not sure how I missed that when I looked on
BitSavers for RH11 stuff! Very illuminating - eventually! The M7294-YA seems
to be a manual ECO to the M7294; there's a detailed rework list on page 6 of
the PDF.

I'm still trying to work out what the changes do. E66 is a 'component
carrier' header, so it seems like in part the ECO adds a bunch of
option-controlling jumpers there (see pg. 2 for a table of what they do).

The main thing, though, seems to be the addition of E22, a 74191 binary
up/down counter, on page DBCA (pg 10 of the PDF). It seems to modify the
operation of 'Bus Hog' mode - maybe to do 16-cycle bursts? (All the
bit inputs and outputs are unused; only the Max/Min output - pin 12 -
is connected to anything.)

That would make sense; with UNIBUS A and B tied together, the original Bus
Hog (below) would lock out the CPU from the RH11 until the end of the
transfer. Actually, though, even without the cross-connect, having
the RH11 going flat out Bus Hog might lock out the CPU from the _KS10
memory_...

> However there is plenty of DEC documentation that mentions that the
> RH11C has a "bus hog" mode for the KS10 disks so that the Unibus can do
> back-to-back 18-bit transactions.

The RH11-AB has Bus Hog too; see Section 4.12.10, "BUS HOG Mode", pg. 4-22
(59 of the PDF) in "RH11-AB Option Description" for details; it "hold[s] the
Unibus ... until the required number of words have been transferred".

Noel

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Rob Doyle via cctalk]

On 11/23/2019 2:10 PM, Noel Chiappa via cctalk wrote:

From: Rob Doyle



Your memory is correct. The RH11C was the buffered version of the
RH11


Umm, both the -AB and -B have FIFOs - confirmed from the prints. (I
have an M7294 if we want to confirm that the prints aren't confused.)
Now, maybe the -C has a _bigger_ FIFO (e.g. large enough to hold a
complete sector), I could definitely see that.

What's your source - I'd like to study/cite it? The only KS10 prints
I can find don't show the RP11-C?

Noel



http://www.bitsavers.org/pdf/dec/unibus/RH11-C_Engineering_Drawings.pdf

Well.  I think you right about that.   I compared the M7294 in the -AB
to the M7294-YA in the -C and they have the same size FIFOs.

Apologies.  I think I was told that incorrectly.

However there is plenty of DEC documentation that mentions that the
RH11C has a "bus hog" mode for the KS10 disks so that the Unibus can do
back-to-back 18-bit transactions.

http://www.bitsavers.org/pdf/dec/pdp10/KS10/ksrefRev2.pdf

Rob.

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Noel Chiappa via cctalk]

> From: Rob Doyle

> Your memory is correct. The RH11C was the buffered version of the RH11

Umm, both the -AB and -B have FIFOs - confirmed from the prints. (I have
an M7294 if we want to confirm that the prints aren't confused.) Now,
maybe the -C has a _bigger_ FIFO (e.g. large enough to hold a complete
sector), I could definitely see that.

What's your source - I'd like to study/cite it? The only KS10 prints I can
find don't show the RP11-C?

Noel

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Pontus Pihlgren via cctalk]

This thread makes me very happy.

I have a KS10 that I'm working on (quite slowly). The PSU is checked out 
and working. Then console seems to work, I can deposit/examine to CRAM 
and RAM.

Next step will be to load micro code and I've been mentally preparing to 
tackle an RH11 emulator for the Unibone.

I'll buy one from Joerg as soon as the second batch is ready and me and 
my KS10 will happily be guinea pigs.

And if I can, I'll help with development.

Regards,
Pontus.

Re: Who changed the gravitational constant (Dec pdp11 stuff)

[Noel Chiappa via cctalk]

> From: Chris Zach

> The MSV11-QC board ... failed startup diagnostics with what looks like
> a stuck bit. .. now I need engineering schematics for that board so I
> can replace one of the 41256 memory chips. On the positive side it looks 
like
> a pretty obvious stuck bit, just need to know which chip is at that
> address and memory location

I suspect you're out of luck on the prints, I think all there is is the
User Manual. Not to worry, it should be pretty easy to create a bit->chip
table, I did that for the MSV11-J:

  https://gunkies.org/wiki/MSV11-J_QBUS_memory#Technical_information

when I needed to repair one; it should be pretty easy to duplicate the
process for the -Q.

I did it with a 2-instruction scope loop, doing a word write to a given
location, floating a '1' bit along a word of '0's, looking at the 'data in'
pin on the DRAM chips. I see the -Q has a 17x8 array of DRAMs, so 16 bits of
data and a parity bit (odd chip out); so in some ways even easier than the -J
(which had ECC). 8 banks, but with a little luck they're in some sort of
logical order.

I have a -QA, of the later etch rev, which is the same etch as your -QC;
so I can help with the mapping process, if you need it; let me know.

Noel

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Rob Doyle via cctalk]

On 11/22/2019 3:05 PM, Eric Smith via cctalk wrote:

One version of the RH11 added a small FIFO (called a "silo" by DEC, IIRC)
in the data path. I don't recall which suffix that was, nor whether it was
the version used in the KS10.


Your memory is correct.  The RH11C was the buffered version of the RH11 
and was used in the KS10.


Rob.

Re: TurboDOS for S-100, IMS or L/F Technologies

[Al Kossow via cctalk]

did anything more ever turn up?
I'd like to try getting a 16-bit 1.43 running, there is a set of disks on ebay, 
but the seller has blocked me
https://www.ebay.com/itm/193098921854

On 6/28/19 7:17 PM, Jonathan Haddox via cctalk wrote:
>  Just sending a thanks for the replies from various folks on this list. I was 
> able to recover a partial set of operating system files for my 
> IMS/LF-Technologies S-100 machine from members who dug deep into their 
> archives. It's booting now to a basic single-user TurboDOS 1.4 which proves 
> that my hardware is sound. In order to get what I really want out of this 
> machine, I still need to source a full set of TurboDOS 1.4 drivers (.REL 
> files) from IMS L/F Tech distribution diskettes. I'll be around if they ever 
> turn up.
> 
> Thank You!
> 
> IMS A645 Z-80 Processor
> IMS A631 serial/parallel I/O
> IMS A930 Floppy controller
> IMS A465 64K RAM
> IMS 1100 Winchester Hard disk controller
> IMS 862 User Processor (Z80)
> IMS 1081 User Processor (186)
> IMS 1120 Tape Controller On Tuesday, June 11, 2019, 11:55:29 AM CDT, 
> Jonathan Haddox  wrote:  
>  
>  I'm restoring an IMS - L/F Technologies S-100 Bus computer.  I've got all 
> the pieces except for the Operating System.  I'm hoping that someone here may 
> have a disk stashed away.  From the literature I have read, I would need 
> TurboDOS version 1.40a or 1.41c from IMS or L/F Technologies.  I've seen 
> TurboDOS 1.3 versions out in the wild from IMS, but the 1.4 version was 
> greatly enhanced and offered better compatibility with my specific hardware.  
> I'd be much obliged if anyone can help.
> 
> Thanks,
> 
> Jonathan
> new_castle_j  at yahoo  
> 

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Noel Chiappa via cctalk]

> the Revision J prints (September 1993).

Ooops, typo: '1973'.

   Noel

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Noel Chiappa via cctalk]

> From: Eric Smith

> One version of the RH11 added a small FIFO (called a "silo" by DEC,
> IIRC) in the data path. I don't recall which suffix that was, nor
> whether it was the version used in the KS10.

Well, the -AB has the FIFO, according to the Revision J prints (September
1993). It's on the M7294 card (see drawings DBCC/D).

Interestingly, I have prints for an RH11-B! That appears to differ by
having an M7295-YA; that differs from the M7295 by having a hand ECO
(i.e. same etch), part of which can been seen in the lower left corner
of drawing BCTB - the two one-shots.

As to the RH11-C, I looked, and we do have the KS10 prints (MP00540,
mis-labelled "KS10_MaintSch" :-), and it does include RH11 prints. Alas,
those show an M7294, not the claimed M9294-YA. :-( The RH11 sheets are also
out of order (some are at the very back of the pack), and DBCD seems to be
missing entirely. They are revision "L", and the RH11-BA prints are revision
"H", FWLTW.

Noel

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Noel Chiappa via cctalk]

> From: Jörg Hoppe

> UniBone can be used in UNIBUS-A SPC slots in 18 bit mode without any
> extra adapters? And can emulate an RH11-C there

As far as I can see, yes.

> even if the RH11 is supposed to run in UNIBUS B?

Well, all RH11's have both UNIBUS A and UNIBUS B; under program control, one
can select either A or B to be the one where the DMA from the RH11 happens.
(Access to the registers in the RH11 is only possible via UNIBUS A, and
interrupts from it can only happen on A.) I'm not sure exactly what your
question is, but I hope that answers it! :-)

> We've seen early SPC slots (PDP-11/40, '45) without NPG wired,
> 'cause SPC was apparently originally meant for "Small" peripherals
> without DMA. Is KS10 UNIBUS-A wired to be DMA capable?

Good question! Well, the RH11 is designed so that it can other devices
'downstream' from it, on both UNIBI. So that says that NPG is sent _through_
the RH11 on both UNIBI - but doesn't speak to the SPC slots. For that, one
needs to look at the backplane wire list - which isn't in the drawings! :-(
However, I happen to have an RH11-AB backplane, and it has the AA1-AB2 jumpers
for NPG on those three slots.

Same thing for interrupts - both UNIBI are wired to for them (although the
grant lines for UNIBUS B don't go into the RH11 cards, they are only on
the RH11 backplane).

Noel

Re: Who changed the gravitational constant (Dec pdp11 stuff)

[Chris Zach via cctalk]

Yeah, it's kind of cool but takes up an insane amount of space. For 
whatever reason I kept it through the decades and it holds the VT52 
perfectly.


Now I'm wondering if it's worth fixing the LS120 that's out in the shed. 
I sold an LA36 about a year or three ago, the LS120 was a weird duck: 
It's an LA36 body with the ability to go 300 and 1200 baud with 120 CPS 
printing. It does *not* have the logic of an LA120, the boards are more 
LA36 and it does not print bi-directionally. Just really moves the old 
head *fast* and probably has a bigger buffer to catch up during a 
carriage return.


Maybe next year.

On 11/22/2019 5:52 PM, Fritz Mueller via cctalk wrote:


On 11/22/19 11:16 AM, Chris Zach via cctalk wrote:

https://i.imgur.com/7BwIwas.jpg


Ah man, I'm jealous of your VT52 roll-around stand -- wish I could find 
one for my VT52!


    --FritzM.

Re: Who changed the gravitational constant (Dec pdp11 stuff)

[Chris Zach via cctalk]

I seem to recall that when the ribbon cable is in backwards, the fault 
light comes on.


True. First cable faults hard (READY/FAULT on) no matter what. Second 
cable would turn off the Fault light and allow spinup (right direction) 
and ready. However when I tried to boot the drive went fault.


Dug out a third (softer, less rigid) cable, same effect. Then I 
remembered I bought the controller working on Ebay some 25 years ago, so 
I went through my pile to find the original controller. Plugged that in...


Drive booted to RSX11M+ 4.2. Great, I have a blown board and a good 
older controller. Enough to get going


During all of this I had a minor setback: The MSV11-QC board (the one 
with 4mb of memory on it stock) failed startup diagnostics with what 
looks like a stuck bit. Used an 11/23+ to verify this and find the 
memory region, now I need engineering schematics for that board so I can 
replace one of the 41256 memory chips. On the positive side it looks 
like a pretty obvious stuck bit, just need to know which chip is at that 
address and memory location


Fortunately I had a Clearmation (I think) backup memory board that has 
only 2Mb of memory. Enough to get going at least...


Never dull. At least I can boot RL02's (will check more cables and such 
today) which means I can get RSX11M up and figure out what went wrong 
with my Hitachi ESDI disk (it's on an MTI controller which is *super 
fast). That's the gold standard, I think it's a 300mb disk in two 
partitions. One has RT11 on it (boots, limited drivers), the other has 
RSX11M 4.0 with all my code, games, programming languages, and so forth. 
When I try to boot that it faults to ODT, which could be a disk read 
failure or possibly something wrong with the monitor. RSX11M 4.0 was 
exceptionally finnicky when it came to devices and maybe something is 
missing and causing it to blow up


C



Paul

On Fri, Nov 22, 2019 at 7:55 PM Chris Zach via cctalk 
mailto:cctalk@classiccmp.org>> wrote:


Normally my answer would be "no". *However* there is mention that
changing 3 jumpers on an RL02 will allow you to read an RL01 pack (not
write).

http://www.pdp-11.nl/peripherals/disk/rl-info.html

So... Maybe. However right now I'm trying to get the disks up. It's
been
20 years, and my cables are not in the best of shape. One cable seems
totally dead, as the RL02 flunks when connected to the controller
(DRIVE
0 and FAULT always on). With the second cable all lights are off and
the
drive spins up and goes ready, however as soon as I try to boot the
drive goes to FAULT. If I remove the 0 drive selector and put in a 1,
the fault goes out, however trying to boot DL1: gives the same error.

This happens on both drives with two different boot packs (old RSXM38
images). So it is either the cable (possible as two pins were bent and
needed to be straightened) or the controller (also a maybe, been 20
years I might have another spare somewhere around here). I'll order
some
DeOXit, ohm out the first cable to see if it's bad, and try again next
weekend.

Never dull. On the positive side I saved at least one set of RL02
rails.
So there is that.

C

On 11/22/2019 2:36 PM, Al Kossow via cctalk wrote:
 >
 >
 > On 11/22/19 11:16 AM, Chris Zach via cctalk wrote:
 >> That
 >> could be a problem if I want to re-load Cobol 81 onto this
RSTS/E system.
 >
 > weren't RL01s usable in an RL02?
 >
 >

RE: Disposing: IBM Microchannel cards, for free

[Dave Wade via cctalk]

Matt,
 Would combined postage be cheaper? I would like a set too but the cost seemed 
horrid
Dave

> -Original Message-
> From: cctalk  On Behalf Of Matt Burke via
> cctalk
> Sent: 23 November 2019 10:30
> To: Guy Dunphy via cctalk 
> Subject: Re: Disposing: IBM Microchannel cards, for free
> 
> Hi Guy,
> 
> I'm interested in the IRMAlink cards, particularly the software and
> documentation as I already have an ISA IRMAlink card and there doesn't seem
> to be any copies online.
> 
> I'm located in the UK so postage will probably be fairly expensive. Are you
> willing to ship the items here?
> 
> Regards,
> 
> Matt
> 
> 
> On 23/11/2019 05:06, Guy Dunphy via cctalk wrote:
> > I'm clearing out some old stuff. These are free (but you pay postage) if
> anyone wants them.
> > Catch: they are in Sydney Australia.
> >
> > ---
> >
> > Digital Communications Associates Inc. Circa 1985 IRMAlink  IRMA 2
> > 3270 Micro-to-Mainframe communications IRMA 2 supplies the personal
> > computer with direct coaxial connection to an IBM 3174, 3274, 3276 or
> > Integral Terminal Controller with Type A adapters.
> >
> > Includes two completes sets, each: card + documentation + 3 x 3.5" disks 
> > with
> code and drivers.
> > Not in original packing.
> >
> > See http://everist.org/spacejunk/sell/irma.htm
> >
> > ---
> >
> > DigiBoard MC/8e Intelligent Async serial communications board (8
> > ports) Circa 1993 One microchannel card plus octopus cable and manuals.
> Some manuals still in sealed envelopes.
> >
> > In original packing
> >
> > See http://everist.org/spacejunk/sell/mc8e.htm
> >
> > ---
> >
> > Guy
> >

Re: Disposing: IBM Microchannel cards, for free

[Matt Burke via cctalk]

Hi Guy,

I'm interested in the IRMAlink cards, particularly the software and
documentation as I already have an ISA IRMAlink card and there doesn't
seem to be any copies online.

I'm located in the UK so postage will probably be fairly expensive. Are
you willing to ship the items here?

Regards,

Matt


On 23/11/2019 05:06, Guy Dunphy via cctalk wrote:
> I'm clearing out some old stuff. These are free (but you pay postage) if 
> anyone wants them.
> Catch: they are in Sydney Australia.
>
> ---
>
> Digital Communications Associates Inc. Circa 1985
> IRMAlink  IRMA 2  3270 Micro-to-Mainframe communications
> IRMA 2 supplies the personal computer with direct coaxial connection
> to an IBM 3174, 3274, 3276 or Integral Terminal Controller with Type A 
> adapters.
>
> Includes two completes sets, each: card + documentation + 3 x 3.5" disks with 
> code and drivers.
> Not in original packing.
>
> See http://everist.org/spacejunk/sell/irma.htm
>
> ---
>
> DigiBoard MC/8e Intelligent Async serial communications board (8 ports) Circa 
> 1993
> One microchannel card plus octopus cable and manuals. Some manuals still in 
> sealed envelopes.
>
> In original packing
>
> See http://everist.org/spacejunk/sell/mc8e.htm
>
> ---
>
> Guy
>

Re: Who changed the gravitational constant (Dec pdp11 stuff)

[Paul Anderson via cctalk]

I seem to recall that when the ribbon cable is in backwards, the fault
light comes on.

Paul

On Fri, Nov 22, 2019 at 7:55 PM Chris Zach via cctalk 
wrote:

> Normally my answer would be "no". *However* there is mention that
> changing 3 jumpers on an RL02 will allow you to read an RL01 pack (not
> write).
>
> http://www.pdp-11.nl/peripherals/disk/rl-info.html
>
> So... Maybe. However right now I'm trying to get the disks up. It's been
> 20 years, and my cables are not in the best of shape. One cable seems
> totally dead, as the RL02 flunks when connected to the controller (DRIVE
> 0 and FAULT always on). With the second cable all lights are off and the
> drive spins up and goes ready, however as soon as I try to boot the
> drive goes to FAULT. If I remove the 0 drive selector and put in a 1,
> the fault goes out, however trying to boot DL1: gives the same error.
>
> This happens on both drives with two different boot packs (old RSXM38
> images). So it is either the cable (possible as two pins were bent and
> needed to be straightened) or the controller (also a maybe, been 20
> years I might have another spare somewhere around here). I'll order some
> DeOXit, ohm out the first cable to see if it's bad, and try again next
> weekend.
>
> Never dull. On the positive side I saved at least one set of RL02 rails.
> So there is that.
>
> C
>
> On 11/22/2019 2:36 PM, Al Kossow via cctalk wrote:
> >
> >
> > On 11/22/19 11:16 AM, Chris Zach via cctalk wrote:
> >> That
> >> could be a problem if I want to re-load Cobol 81 onto this RSTS/E
> system.
> >
> > weren't RL01s usable in an RL02?
> >
> >
>

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

2. When doing 18bit on UNIBUS-A we put all kind of signal levels
on parity lines PA,PB = DATA<16:17>.
Won't the KS10 CPU interpret these as real BUS parity errors generated
by some UNIBUS-A device?


I asked nonsense here: if UNIBUS-A is 18bit too, no parity will be evaluted of 
course.

Joerg