Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Paul Anderson via cctalk
If you want a different box or boards, feel free to contact me off list.

Where are you located?

On Wed, Aug 30, 2017 at 11:02 AM, Douglas Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 8/30/2017 5:53 AM, Pete Turnbull via cctech wrote:
>
>> On 30/08/2017 05:29, Douglas Taylor via cctalk wrote:
>>
>>> I'll send along a picture of the rear of the back plane.  I'm getting
>>>  the impression I can't do what I want with the old cpu cards, M7270
>>> and M7264.
>>>
>>> I had really hoped to be able to put together a simple system to
>>> demonstrate the differences in processing power between the 11/2 cpu,
>>>  the 11/23 and the 11/73.
>>>
>>> They are all dual width cards and it would have been simple to swap
>>> them out.  I think to do it I would need 2 boxes, one with a 16 bit
>>> backplane and the other with a 22 bit backplane.
>>>
>>
>> I don't see why you couldn't do what you want with the BA11-M and a
>> little work, *providing* the Emulex UC07 controller works in an LSI-1103
>> system - and the manual (on Bitsavers) suggests it should.  Section 1.6.3
>> says "The UC07/08 is compatible with the Q-Bus used on all LSI-11 ...
>> series computers."
>>
>> First, you'd need to undo any backplane upgrade that made it 22-bit
>> instead of 18-bit.  BTW, there's no such thing as a 16-bit backplane, only
>> 18-bit and 22-bit.  BDAL17/18 are always bussed, to allow for the use of
>> parity, even in 16-bit-CPU systems such as an 11/03.
>>
>> The only reason you need to do this is that the KD11-H and KD11-F
>> processors put other signals on those lines, which the Emulex (and other
>> 22-bit devices) won't like and will interfere with.
>>
>> The soldering you mentioned is almost certainly the extra four bus lines
>> for the upgrade.  It will be on both the B and D fingers of the backplane,
>> because it's a serpentine backplane with Q-Bus on both sides.  Look for
>> wired connections between BC1, BD1, BE1, BF1 and between DC1, DD1, DE1,
>> DF1.  Check there no other extra connections; sometimes people added
>> connections for other signals - for example I have a backplane with the
>> SRUN signal on extra slots for diagnostics and faultfinding. Also check you
>> don't have an H9270-Q, which is inherently 22-bit, instead of an H9270.
>> I've never seen one, but presumably they exist.
>>
>> See http://www.dunnington.info/public/PDP-11/QBus_chassis for a little
>> more information.
>>
>> Next you'd need some sort of bootstrap.  What's in the custom EPROMs on
>> you MXV11-AC might do.  Or might not, depending on whether it uses any
>> 11/23 (KDF-11) specific instructions or diagnostics, and includes an MSCP
>> bootstrap.  The autoboot feature on the UC07 might do instead.  Or might
>> not.  You'd have to experiment.
>>
>> If you do keep the MXV11-AC, you've already got 32KB of memory that works
>> with any of your 11/03, 11/23, or 11/73 processors, and you have two
>> DLV11-compatible serial ports.  In fact the serial ports are virtually
>> identical to half of a DLV11-J.  Since RT11 rarely has any use for more
>> than two, you probably don't need any more.
>>
>> If you keep the MXV11-AC and re-enable the memory, you only want another
>> 32KB, and maybe not even that.  I can't remember if RT11 5.3 will run in
>> 32KB; it probably will, and I'm sure it would if suitably SYSGENned.  I do
>> remember RT11 5.6 either didn't or didn't unless it was seriously pared
>> down.  Don't use anything older than 5.3 because there are bugs in the MSCP
>> drivers that prevent it working with just about anything other than RQDX1/2
>> interfaces.
>>
>> Or you could probably use the MSV11-P.  It works in 18-bit systems, and
>> should still work in a 16-bit (CPU) system, but obviously you'd only be
>> using the bottom 64KB.  If you want "period" memory to match the 11/03, you
>> could find an MSV11-DC or -DD to use instead.  The -DC has 32KB to
>> supplement your MXV11-AC; the -DD has 64KB.  The -EC and ED versions are
>> the same boards but with parity circuitry added, which makes them less
>> common and more expensive, but they'd also do what you want.
>>
>> Hope this helps...
>>
>> Yes, it does help.  There are 3 issues that I am trying to resolve:
>
> 1. Running in 32kb of memory.   If I use the 32kb MXV11 can I run RT11
> V5.3?  I tried this in SIMH and set the Cpu to 11/03 and memory to 32kb and
> it did work.  The MXV11 has PROM and is set to boot  from it, but it is not
> a device boot.  This BA11-M was connected to a MicroVaxII and was set up to
> answer telephones for the Univ of Wisc.  I got this about 15 years ago and
> I think I looked what was coming across the console line and I remember DL
> showing up or something like that.  The MXV11-AC is devilishly tough to
> setup, all those wire wrap jumpers and I've misplaced my wire wrap tool.
>
> 2. Bootstrap. I transferred the RT11 V5.3 to a DEC 535MB SCSI disk and was
> able to boot it using an Alphatronix SCSI controller, it is a Viking QDO
> rebadged.  It only can see 

Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Jerry Weiss via cctalk

> On Aug 30, 2017, at 9:52 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Jerry Weiss
> 
>> The processor will probably halt due to non-existent memory address.
> 
> No, it'll take a NXM trap (through 4); what happens then depends on what the
> trap handler is set to - if anything.
> 
>> However, a P entered in ODT will attempt to continue the bootstrap.
> 
> See above. I wouldn't bet on a 'P' doing anything useful.
> 
>> If you have and cannot disable the LTC, it may work intermittently,
>> depending on whether LTC interrupt occurs before he OS bootstrap loads.
>> Its just a matter of timing.
> 
> You could set the PS to 340 and the PC to the start of the bootstrap, and do
> a 'P' to start it running. (Using 'G' to start the bootstrap will clear the
> PS.)
> 
> But I guess you've still got the NXM trap to contend with. If the bootstrap
> doesn't set the trap handler up, you could manually key in the vector (at 4)
> and a real simple trap handler (e.g. just dismiss, with an RTI), and you also
> might have to set up the SP.
> 

I stand corrected on the NXM trap. However back in the day, we had a few LSI 
systems 
without an external LTC control that would not boot consistently.   The “P” 
trick worked,
perhaps owing to a double bus error…. (R6 not set up correctly).  We never got 
into the
details.

As I mentioned in my own followup, the UC07 uses Power On Option to recover via
the power trap.  This sets the PSW without an instruction, avoiding any code 
that would
have to select between a MTPS or MOV #340,@#PSW.  

The FRD bootstrap for the UC07 instructs the user to use ODT to set the PSW,but 
I don’t
see how code @200 would work on an LSI 11/1 or 11/03 unless that 04 vector is 
set up
and handles he recovery as Noel suggests.  





Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Pete Turnbull via cctalk

On 30/08/2017 17:02, Douglas Taylor via cctalk wrote:

On 8/30/2017 5:53 AM, Pete Turnbull via cctech wrote:

Hope this helps...


Yes, it does help.  There are 3 issues that I am trying to resolve:

1. Running in 32kb of memory.   If I use the 32kb MXV11 can I run RT11 
V5.3?


If it works in SIMH it should be just the same on real hardware - modulo 
any backplane bitness issues.


2. Bootstrap. I transferred the RT11 V5.3 to a DEC 535MB SCSI disk and 
was able to boot it using an Alphatronix SCSI controller, it is a Viking 
QDO rebadged.  When I say is was able to boot it, I 
connected it to a 11/53 CPU in a BA23 box just to test it out.


That has a J11 CPU, same as your 11/73, with the same registers.  So I'd 
be guided by others'  comments on booting the UC07.  You could of course 
program the MSCP bootstrap and whatever else you need for setup into a 
pair of EPROMs but that's perhaps not a good place to start.


3. 18 Bit addressing.  It appears that the H9270 backplane I have has 
been modified by DEC with wire wrap and soldered in connections.  I 
really, really don't want to undo any of that.  I may have to settle for 
just running an 11/23, 11/53 and 11/73 cpu in this box.


I doubt if it was done by DEC, unless some failed servoid did it as a 
favour for the previous owner when upgrading it for the 11/23.  It was a 
common user upgrade, though.


--
Pete
Pete Turnbull


Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Douglas Taylor via cctalk

On 8/30/2017 5:53 AM, Pete Turnbull via cctech wrote:

On 30/08/2017 05:29, Douglas Taylor via cctalk wrote:

I'll send along a picture of the rear of the back plane.  I'm getting
 the impression I can't do what I want with the old cpu cards, M7270
and M7264.

I had really hoped to be able to put together a simple system to 
demonstrate the differences in processing power between the 11/2 cpu,

 the 11/23 and the 11/73.

They are all dual width cards and it would have been simple to swap
them out.  I think to do it I would need 2 boxes, one with a 16 bit
backplane and the other with a 22 bit backplane.


I don't see why you couldn't do what you want with the BA11-M and a 
little work, *providing* the Emulex UC07 controller works in an 
LSI-1103 system - and the manual (on Bitsavers) suggests it should.  
Section 1.6.3 says "The UC07/08 is compatible with the Q-Bus used on 
all LSI-11 ... series computers."


First, you'd need to undo any backplane upgrade that made it 22-bit 
instead of 18-bit.  BTW, there's no such thing as a 16-bit backplane, 
only 18-bit and 22-bit.  BDAL17/18 are always bussed, to allow for the 
use of parity, even in 16-bit-CPU systems such as an 11/03.


The only reason you need to do this is that the KD11-H and KD11-F 
processors put other signals on those lines, which the Emulex (and 
other 22-bit devices) won't like and will interfere with.


The soldering you mentioned is almost certainly the extra four bus 
lines for the upgrade.  It will be on both the B and D fingers of the 
backplane, because it's a serpentine backplane with Q-Bus on both 
sides.  Look for wired connections between BC1, BD1, BE1, BF1 and 
between DC1, DD1, DE1, DF1.  Check there no other extra connections; 
sometimes people added connections for other signals - for example I 
have a backplane with the SRUN signal on extra slots for diagnostics 
and faultfinding. Also check you don't have an H9270-Q, which is 
inherently 22-bit, instead of an H9270.  I've never seen one, but 
presumably they exist.


See http://www.dunnington.info/public/PDP-11/QBus_chassis for a little 
more information.


Next you'd need some sort of bootstrap.  What's in the custom EPROMs 
on you MXV11-AC might do.  Or might not, depending on whether it uses 
any 11/23 (KDF-11) specific instructions or diagnostics, and includes 
an MSCP bootstrap.  The autoboot feature on the UC07 might do 
instead.  Or might not.  You'd have to experiment.


If you do keep the MXV11-AC, you've already got 32KB of memory that 
works with any of your 11/03, 11/23, or 11/73 processors, and you have 
two DLV11-compatible serial ports.  In fact the serial ports are 
virtually identical to half of a DLV11-J.  Since RT11 rarely has any 
use for more than two, you probably don't need any more.


If you keep the MXV11-AC and re-enable the memory, you only want 
another 32KB, and maybe not even that.  I can't remember if RT11 5.3 
will run in 32KB; it probably will, and I'm sure it would if suitably 
SYSGENned.  I do remember RT11 5.6 either didn't or didn't unless it 
was seriously pared down.  Don't use anything older than 5.3 because 
there are bugs in the MSCP drivers that prevent it working with just 
about anything other than RQDX1/2 interfaces.


Or you could probably use the MSV11-P.  It works in 18-bit systems, 
and should still work in a 16-bit (CPU) system, but obviously you'd 
only be using the bottom 64KB.  If you want "period" memory to match 
the 11/03, you could find an MSV11-DC or -DD to use instead.  The -DC 
has 32KB to supplement your MXV11-AC; the -DD has 64KB.  The -EC and 
ED versions are the same boards but with parity circuitry added, which 
makes them less common and more expensive, but they'd also do what you 
want.


Hope this helps...


Yes, it does help.  There are 3 issues that I am trying to resolve:

1. Running in 32kb of memory.   If I use the 32kb MXV11 can I run RT11 
V5.3?  I tried this in SIMH and set the Cpu to 11/03 and memory to 32kb 
and it did work.  The MXV11 has PROM and is set to boot  from it, but it 
is not a device boot.  This BA11-M was connected to a MicroVaxII and was 
set up to answer telephones for the Univ of Wisc.  I got this about 15 
years ago and I think I looked what was coming across the console line 
and I remember DL showing up or something like that.  The MXV11-AC is 
devilishly tough to setup, all those wire wrap jumpers and I've 
misplaced my wire wrap tool.


2. Bootstrap. I transferred the RT11 V5.3 to a DEC 535MB SCSI disk and 
was able to boot it using an Alphatronix SCSI controller, it is a Viking 
QDO rebadged.  It only can see 2 disks at a time, but auto configures on 
startup, unlike the UC07.  When I say is was able to boot it, I 
connected it to a 11/53 CPU in a BA23 box just to test it out.  The QDO 
doesn't have a native bootstrap so that's why I began thinking about the 
UC07.  The manual says it has an auto-boot for LSI-11 only, but the 
details were few. Someone else pointed out the 

Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Noel Chiappa via cctalk
> From: Jerry Weiss

> The processor will probably halt due to non-existent memory address.

No, it'll take a NXM trap (through 4); what happens then depends on what the
trap handler is set to - if anything.

> However, a P entered in ODT will attempt to continue the bootstrap.

See above. I wouldn't bet on a 'P' doing anything useful.

> If you have and cannot disable the LTC, it may work intermittently,
> depending on whether LTC interrupt occurs before he OS bootstrap loads.
> Its just a matter of timing.

You could set the PS to 340 and the PC to the start of the bootstrap, and do
a 'P' to start it running. (Using 'G' to start the bootstrap will clear the
PS.)

But I guess you've still got the NXM trap to contend with. If the bootstrap
doesn't set the trap handler up, you could manually key in the vector (at 4)
and a real simple trap handler (e.g. just dismiss, with an RTI), and you also
might have to set up the SP.

Noel


Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Jerry Weiss via cctalk

> On Aug 30, 2017, at 8:04 AM, Jerry Weiss  wrote:
> 
>> 
>> Next you'd need some sort of bootstrap.  What's in the custom EPROMs on you 
>> MXV11-AC might do.  Or might not, depending on whether it uses any 11/23 
>> (KDF-11) specific instructions or diagnostics, and includes an MSCP 
>> bootstrap.  The autoboot feature on the UC07 might do instead.  Or might 
>> not.  You'd have to experiment.
>> 
> 
> The autoboot on the UC07 uses the following instruction for the REV G 
> firmware.
> 
>   200:MOV #340,@#16
> 
> The memory mapped register (CSR 16) for the processor status word (PSW) 
> does not exist  on the LSI-11.  
> The purpose of this is to prevent interrupts during bootstraping from the LTC 
> and other devices.  The processor will probably halt due to non-existent 
> memory address.
> 
> However, a P entered in ODT will attempt to continue the bootstrap.  If you 
> have and cannot disable the LTC, it may work intermittently, depending on 
> whether LTC interrupt occurs before he OS bootstrap loads.   Its just a 
> matter of timing.


One clarification.

The UC07 can be configured to use Power Up Option 0 on the LSI 11 
(PC@24,PSW@26) too boot.  
This method probably avoids the problem with the manually invoked Bootstrap or 
FRD 
using an addressable PSW that some users reported.




Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Jerry Weiss via cctalk
> On Aug 30, 2017, at 4:53 AM, Pete Turnbull via cctalk  
> wrote:
> 
> On 30/08/2017 05:29, Douglas Taylor via cctalk wrote:
>> I'll send along a picture of the rear of the back plane.  I'm getting
>> the impression I can't do what I want with the old cpu cards, M7270
>> and M7264.
>> I had really hoped to be able to put together a simple system to demonstrate 
>> the differences in processing power between the 11/2 cpu,
>> the 11/23 and the 11/73.
>> They are all dual width cards and it would have been simple to swap
>> them out.  I think to do it I would need 2 boxes, one with a 16 bit
>> backplane and the other with a 22 bit backplane.
> 
> I don't see why you couldn't do what you want with the BA11-M and a little 
> work, *providing* the Emulex UC07 controller works in an LSI-1103 system - 
> and the manual (on Bitsavers) suggests it should.  Section 1.6.3 says "The 
> UC07/08 is compatible with the Q-Bus used on all LSI-11 ... series computers."
> 
> First, you'd need to undo any backplane upgrade that made it 22-bit instead 
> of 18-bit.  BTW, there's no such thing as a 16-bit backplane, only 18-bit and 
> 22-bit.  BDAL17/18 are always bussed, to allow for the use of parity, even in 
> 16-bit-CPU systems such as an 11/03.
> 
> The only reason you need to do this is that the KD11-H and KD11-F processors 
> put other signals on those lines, which the Emulex (and other 22-bit devices) 
> won't like and will interfere with.
> 
> The soldering you mentioned is almost certainly the extra four bus lines for 
> the upgrade.  It will be on both the B and D fingers of the backplane, 
> because it's a serpentine backplane with Q-Bus on both sides.  Look for wired 
> connections between BC1, BD1, BE1, BF1 and between DC1, DD1, DE1, DF1.  Check 
> there no other extra connections; sometimes people added connections for 
> other signals - for example I have a backplane with the SRUN signal on extra 
> slots for diagnostics and faultfinding. Also check you don't have an H9270-Q, 
> which is inherently 22-bit, instead of an H9270.  I've never seen one, but 
> presumably they exist.
> 
> See http://www.dunnington.info/public/PDP-11/QBus_chassis for a little more 
> information.

Agree with Pete here.  The UC07 manual includes jumper settings for an LSI 
11/2, so we can assume it was supported (UC0751001H).
Provided you have an 18 bit bus which means that BC1/DC1, 
BD1/DD1,BE1/DE1,BF1/DF1 are NOT bussed,  the LSI 11/2,11/03 and an UC07 should 
work together.   

> 
> Next you'd need some sort of bootstrap.  What's in the custom EPROMs on you 
> MXV11-AC might do.  Or might not, depending on whether it uses any 11/23 
> (KDF-11) specific instructions or diagnostics, and includes an MSCP 
> bootstrap.  The autoboot feature on the UC07 might do instead.  Or might not. 
>  You'd have to experiment.
> 

The autoboot on the UC07 uses the following instruction for the REV G firmware.

200:MOV #340,@#16

The memory mapped register (CSR 16) for the processor status word (PSW) 
does not exist  on the LSI-11.  
The purpose of this is to prevent interrupts during bootstraping from the LTC 
and other devices.  The processor will probably halt due to non-existent memory 
address.

However, a P entered in ODT will attempt to continue the bootstrap.  If you 
have and cannot disable the LTC, it may work intermittently, depending on 
whether LTC interrupt occurs before he OS bootstrap loads.   Its just a matter 
of timing.


Jerry





Re: DEC ll/03 in 22 bit backplane

2017-08-30 Thread Pete Turnbull via cctalk

On 30/08/2017 05:29, Douglas Taylor via cctalk wrote:

I'll send along a picture of the rear of the back plane.  I'm getting
 the impression I can't do what I want with the old cpu cards, M7270
and M7264.

I had really hoped to be able to put together a simple system to 
demonstrate the differences in processing power between the 11/2 cpu,

 the 11/23 and the 11/73.

They are all dual width cards and it would have been simple to swap
them out.  I think to do it I would need 2 boxes, one with a 16 bit
backplane and the other with a 22 bit backplane.


I don't see why you couldn't do what you want with the BA11-M and a 
little work, *providing* the Emulex UC07 controller works in an LSI-1103 
system - and the manual (on Bitsavers) suggests it should.  Section 
1.6.3 says "The UC07/08 is compatible with the Q-Bus used on all LSI-11 
... series computers."


First, you'd need to undo any backplane upgrade that made it 22-bit 
instead of 18-bit.  BTW, there's no such thing as a 16-bit backplane, 
only 18-bit and 22-bit.  BDAL17/18 are always bussed, to allow for the 
use of parity, even in 16-bit-CPU systems such as an 11/03.


The only reason you need to do this is that the KD11-H and KD11-F 
processors put other signals on those lines, which the Emulex (and other 
22-bit devices) won't like and will interfere with.


The soldering you mentioned is almost certainly the extra four bus lines 
for the upgrade.  It will be on both the B and D fingers of the 
backplane, because it's a serpentine backplane with Q-Bus on both sides. 
 Look for wired connections between BC1, BD1, BE1, BF1 and between DC1, 
DD1, DE1, DF1.  Check there no other extra connections; sometimes people 
added connections for other signals - for example I have a backplane 
with the SRUN signal on extra slots for diagnostics and faultfinding. 
Also check you don't have an H9270-Q, which is inherently 22-bit, 
instead of an H9270.  I've never seen one, but presumably they exist.


See http://www.dunnington.info/public/PDP-11/QBus_chassis for a little 
more information.


Next you'd need some sort of bootstrap.  What's in the custom EPROMs on 
you MXV11-AC might do.  Or might not, depending on whether it uses any 
11/23 (KDF-11) specific instructions or diagnostics, and includes an 
MSCP bootstrap.  The autoboot feature on the UC07 might do instead.  Or 
might not.  You'd have to experiment.


If you do keep the MXV11-AC, you've already got 32KB of memory that 
works with any of your 11/03, 11/23, or 11/73 processors, and you have 
two DLV11-compatible serial ports.  In fact the serial ports are 
virtually identical to half of a DLV11-J.  Since RT11 rarely has any use 
for more than two, you probably don't need any more.


If you keep the MXV11-AC and re-enable the memory, you only want another 
32KB, and maybe not even that.  I can't remember if RT11 5.3 will run in 
32KB; it probably will, and I'm sure it would if suitably SYSGENned.  I 
do remember RT11 5.6 either didn't or didn't unless it was seriously 
pared down.  Don't use anything older than 5.3 because there are bugs in 
the MSCP drivers that prevent it working with just about anything other 
than RQDX1/2 interfaces.


Or you could probably use the MSV11-P.  It works in 18-bit systems, and 
should still work in a 16-bit (CPU) system, but obviously you'd only be 
using the bottom 64KB.  If you want "period" memory to match the 11/03, 
you could find an MSV11-DC or -DD to use instead.  The -DC has 32KB to 
supplement your MXV11-AC; the -DD has 64KB.  The -EC and ED versions are 
the same boards but with parity circuitry added, which makes them less 
common and more expensive, but they'd also do what you want.


Hope this helps...

--
Pete
Pete Turnbull


Re: DEC ll/03 in 22 bit backplane

2017-08-29 Thread Douglas Taylor via cctalk

On 8/30/2017 12:10 AM, Ethan Dicks wrote:

On Tue, Aug 29, 2017 at 10:52 PM, Douglas Taylor via cctalk
 wrote:

I have a BA11-M box with a backplane that I am sure has been upgraded to be
22 bit addressing.

If you send me a picture of the backplane part of the box (without the
outer shroud), I might be able to help.   I think I have some 4x4 Qbus
backplanes, which are likely to be Q16 or Q18 not Q22 that have no box
but may be the former contents of a BA11-M.  I know they aren't part
of a BA11-N, because I have 2 of those that I use with RLV11s.  The
paper tag on the backplane says "LSI-11" (the type of tag that might
say DD11-CK or DD11-DK when applied to those backplanes).


If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial
cards for sale/trade?

I think those cards are easy to find.  Among the most common Qbus
cards.  I have some, as do others on this list.

-ethan


I'll send along a picture of the rear of the back plane.  I'm getting 
the impression I can't do what I want with the old cpu cards, M7270 and 
M7264.


I had really hoped to be able to put together a simple system to 
demonstrate the differences in processing power between the 11/2 cpu, 
the 11/23 and the 11/73.


They are all dual width cards and it would have been simple to swap them 
out.  I think to do it I would need 2 boxes, one with a 16 bit backplane 
and the other with a 22 bit backplane.




Re: DEC ll/03 in 22 bit backplane

2017-08-29 Thread Douglas Taylor via cctalk

On 8/29/2017 11:43 PM, Jerry Weiss via cctalk wrote:

On Aug 29, 2017, at 9:52 PM, Douglas Taylor via cctalk  
wrote:

I have a BA11-M box with a backplane that I am sure has been upgraded to be 22 
bit addressing.

When I got this box it had an 11/23 Dual width Cpu, MXV11-AC with custom boot 
ROMs and a 256KB MSV11-P memory board.  The memory in the MXV11 had been 
disabled so I suspect the backplane was upgraded to 22 bit.

What I want to do is put a LSI 11/2 (M7270) and/or LSI 11/03 (M7264) into this 
box and construct a minimal, basic PDP11.  This system would have 64kb of 
memory, some kind of serial interface and an Emulex UC07 running a SCSI disk or 
SCSI2SD adapter.  The OS would be RT11 V5.3.

Can I operate these Cpu's in a 22 bit backplane?

If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial cards 
for sale/trade?



Micronote 5 does not list the LSI 11/2 or 11/03 processors as being compatible 
with Q22.
See section II oin  http://decvax.50megs.com/doc/uNotes/micronote5.html 
 for the details.

The upgrades to Q22 were commonly done with wire-wrap.  You could unwrap the 
modification.


I think I've seen those in the past.  The backplane I have has something 
soldered on each side of the backplane (in the rear, where the wire wrap 
pins are).


The micronote says that I can't do what I want to do.  The 11/2 and 
11/03 Cpus use some of those address lines for something else.  So I 
couldn't use the UC07.


It looks like a trip down memory lane that I can't make.



Re: DEC ll/03 in 22 bit backplane

2017-08-29 Thread Ethan Dicks via cctalk
On Tue, Aug 29, 2017 at 10:52 PM, Douglas Taylor via cctalk
 wrote:
> I have a BA11-M box with a backplane that I am sure has been upgraded to be
> 22 bit addressing.

If you send me a picture of the backplane part of the box (without the
outer shroud), I might be able to help.   I think I have some 4x4 Qbus
backplanes, which are likely to be Q16 or Q18 not Q22 that have no box
but may be the former contents of a BA11-M.  I know they aren't part
of a BA11-N, because I have 2 of those that I use with RLV11s.  The
paper tag on the backplane says "LSI-11" (the type of tag that might
say DD11-CK or DD11-DK when applied to those backplanes).

> If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial
> cards for sale/trade?

I think those cards are easy to find.  Among the most common Qbus
cards.  I have some, as do others on this list.

-ethan


Re: DEC ll/03 in 22 bit backplane

2017-08-29 Thread Jerry Weiss via cctalk

> On Aug 29, 2017, at 9:52 PM, Douglas Taylor via cctalk 
>  wrote:
> 
> I have a BA11-M box with a backplane that I am sure has been upgraded to be 
> 22 bit addressing.
> 
> When I got this box it had an 11/23 Dual width Cpu, MXV11-AC with custom boot 
> ROMs and a 256KB MSV11-P memory board.  The memory in the MXV11 had been 
> disabled so I suspect the backplane was upgraded to 22 bit.
> 
> What I want to do is put a LSI 11/2 (M7270) and/or LSI 11/03 (M7264) into 
> this box and construct a minimal, basic PDP11.  This system would have 64kb 
> of memory, some kind of serial interface and an Emulex UC07 running a SCSI 
> disk or SCSI2SD adapter.  The OS would be RT11 V5.3.
> 
> Can I operate these Cpu's in a 22 bit backplane?
> 
> If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial 
> cards for sale/trade?
> 
> 

Micronote 5 does not list the LSI 11/2 or 11/03 processors as being compatible 
with Q22. 
See section II oin  http://decvax.50megs.com/doc/uNotes/micronote5.html 
 for the details.

The upgrades to Q22 were commonly done with wire-wrap.  You could unwrap the 
modification.




Re: DEC ll/03 in 22 bit backplane

2017-08-29 Thread Paul Anderson via cctalk
I have the DEC cards, but I think that box had a 4 x 4 backplane and came
with 16 bit addressing (M7264) and could be upgraded to 18.  I'm out of
town so I can't really check. You might need a BA11-N, S, or BA23 box to
support the Emulex controller.

The Q-bus backplanes can be confusing and I don't trust my memory on them.

Paul

On Tue, Aug 29, 2017 at 9:52 PM, Douglas Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I have a BA11-M box with a backplane that I am sure has been upgraded to
> be 22 bit addressing.
>
> When I got this box it had an 11/23 Dual width Cpu, MXV11-AC with custom
> boot ROMs and a 256KB MSV11-P memory board.  The memory in the MXV11 had
> been disabled so I suspect the backplane was upgraded to 22 bit.
>
> What I want to do is put a LSI 11/2 (M7270) and/or LSI 11/03 (M7264) into
> this box and construct a minimal, basic PDP11.  This system would have 64kb
> of memory, some kind of serial interface and an Emulex UC07 running a SCSI
> disk or SCSI2SD adapter.  The OS would be RT11 V5.3.
>
> Can I operate these Cpu's in a 22 bit backplane?
>
> If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial
> cards for sale/trade?
>
>
>


DEC ll/03 in 22 bit backplane

2017-08-29 Thread Douglas Taylor via cctalk
I have a BA11-M box with a backplane that I am sure has been upgraded to 
be 22 bit addressing.


When I got this box it had an 11/23 Dual width Cpu, MXV11-AC with custom 
boot ROMs and a 256KB MSV11-P memory board.  The memory in the MXV11 had 
been disabled so I suspect the backplane was upgraded to 22 bit.


What I want to do is put a LSI 11/2 (M7270) and/or LSI 11/03 (M7264) 
into this box and construct a minimal, basic PDP11.  This system would 
have 64kb of memory, some kind of serial interface and an Emulex UC07 
running a SCSI disk or SCSI2SD adapter.  The OS would be RT11 V5.3.


Can I operate these Cpu's in a 22 bit backplane?

If so, does anyone have spare MSV11-DD 64kb memory and DLV11 type serial 
cards for sale/trade?