[cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line)

[Jerry Weiss via cctalk]

While intention might have been to last XX years, I am becoming
increasingly pessimistic about longevity of most electronic devices.  A
crystal radio with an open air capacitor seems like the only good bet.
Between electrolytic capacitor aging challenges, discrete and integrated
circuit hermetic failures, cost or other inherent technical flaws, I fear
most electronics will become inert over time.  Many of us have the skills
to identify and replace bits to extend the lifetime of many items. I only
hope the skills and suitable replacement parts are available as time goes
on.

[cctalk] Re: How to shutdown RT11?

[Jerry Weiss via cctalk]

I make sure that any disk squeeze is complete and other programs are 
quiescence.


Then I just halt the processor or emulator.

 Jerry

On 3/22/24 8:23 AM, Paul Koning via cctalk wrote:



On Mar 21, 2024, at 9:35 PM, W2HX via cctalk  wrote:

Ok, Bill. Still feels strange. No need to park the HD head either I guess.

DEC disks do that themselves, at power down.

paul

Re: Using tu58fs with RT11 5.7

[Jerry Weiss via cctalk]

On 5/5/22 8:30 PM, Douglas Taylor via cctalk wrote:
I wanted to try using tu58fs with a RT11 system running version 5.7 to 
transfer files in/out.


To my surprise RT11 5.7 retired the DD: device, a DD.MAC file is 
there, but it is unsupported.


(1) How do you compile a device driver file?  How do you link and 
install it?


(2) Has anyone done this?

(3) Is anyone using tu58fs with a RT11 5.7 system?

Doug

If you are using one of the distributed 5.7 monitors, try taking one 
from an earlier & similar version like 5.6.  The 5.7 changes did not 
impact handlers like this IIRC.


Of course if you want the build experience, check out the 5.6 device 
handlers manual.


  Jerry

Re: DEC AXV11-C analog board

[Jerry Weiss via cctalk]

These A/D systems use methods to isolate the sensitive analog signals 
from the electrical noise and ground plane of the computer.  Typically a 
differential input is standard, so you will probably need wire up two 
inputs.


If this is your first time with A/D, suggest you toggle in some code to 
trigger and report the A/D conversion repeatedly and use a small voltage 
battery with a potentiometer divider to drive the inputs.  Most of 
the analog inputs should be high impedance and while not impervious, can 
take +- 30v w/o damage.


 Jerry




On 2/6/22 11:43 AM, Douglas Taylor via cctalk wrote:
Yes, I am putting 1 into the CSR to start the conversion and I do get 
a 200(8) indicating that the conversion is complete.  I wonder if this 
means the A/D chip is OK but something else, like the multiplexer chip 
or gain amp is fried.


On 2/6/2022 12:33 PM, Jerry Weiss via cctalk wrote:
Are you triggering an A/D conversion via the CSR or external signal?  
Then check the A/D done bit.


See  EK-AXV11-UG-02 Chapter 4.

   Jerry

On 2/6/22 11:20 AM, Douglas Taylor via cctalk wrote:
I have one of these and would like to use it, however it appears to 
only partially work.  Here is what I have found that works and what 
doesn't:


1. CSR and DBR are present and operational.

2. Jumpers set to 'factory'.

3. D/A portion works, can deposit codes in ODT and see voltages out 
on DAC pins that change depending on the octal value deposited in 
CSR+4 or +6.


4. A/D portion returns full scale code, either 3777 (2's compliment) 
or  (offset binary) whether in the input is open or shorted to gnd.


I think the problem is that the A/D inputs are not exactly protected 
and damage has occurred to this portion in the past.


Does anyone have any info on the A/D module?  Who made it? Can you 
open it up?  Does XXDP have a test for this?


Doug

Re: DEC AXV11-C analog board

[Jerry Weiss via cctalk]

Are you triggering an A/D conversion via the CSR or external signal?  
Then check the A/D done bit.


See  EK-AXV11-UG-02 Chapter 4.

   Jerry

On 2/6/22 11:20 AM, Douglas Taylor via cctalk wrote:
I have one of these and would like to use it, however it appears to 
only partially work.  Here is what I have found that works and what 
doesn't:


1. CSR and DBR are present and operational.

2. Jumpers set to 'factory'.

3. D/A portion works, can deposit codes in ODT and see voltages out on 
DAC pins that change depending on the octal value deposited in CSR+4 
or +6.


4. A/D portion returns full scale code, either 3777 (2's compliment) 
or  (offset binary) whether in the input is open or shorted to gnd.


I think the problem is that the A/D inputs are not exactly protected 
and damage has occurred to this portion in the past.


Does anyone have any info on the A/D module?  Who made it?  Can you 
open it up?  Does XXDP have a test for this?


Doug

Re: External SCSI Drives on DEC2000 AXP

[Jerry Weiss via cctalk]

DEC was were specific about the settings for SCSI mode that MicroVAX 
3100 firmware and VAX/VMS would accept before enabling third party 
drives in that era.   Not all early drives that would accurately 
do/report media recovery operations.


Suggest you look at this post and compare to the SCSI drive settings.   
Its a bit of work, but I have updated the mode settings for drives used 
on my MicroVAX's.  I cannot speak for the DEC2000.


https://groups.google.com/g/comp.os.vms/c/RAaUpP_XXEw/m/BWn64YZYwBQJ

Jerry


On 12/5/21 9:08 AM, Bill Degnan via cctalk wrote:dec2000

Nigel,
If you have two drives of the same volume name in VMS that will cause
issues.  You did not provide a lot of detail to give you specific answers.

Its complex but here is a starting point
https://www.vintagecomputer.net/browse_thread_record.cfm?id=604=18

I am a hobbyist in vms, not an expert.

Bill

On Sun, Dec 5, 2021, 8:46 AM Nigel Johnson Ham via cctalk <
cctalk@classiccmp.org> wrote:


I am trying to format a couple of SCSI drives on the Alpha.  They are
connected using the external cable and are mounted in an Open Storage
Systems (OSS) box. The drives were working when removed from a PC.

SRM shows only one of them coming up as DKA200.  I have set the two
drive ID switches to 2 and 3.

Lack of info is hampering me, I have gleaned form various sources that
the following command should work:


t scsi format a 2 0

which just returns


OK

immediately, without doing anything.

VMS allows me to ini the disk, but then when I try to mount it, I get an
operator services message saying it is offline, please mount volume in
_$3$dka200:

Anybody with experience here?

cheers,

Nigel


--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype:  tilbury2591nw.john...@ieee.org

Re: Looking for info on memory

[Jerry Weiss via cctalk]

On 10/20/21 7:10 PM, Nigel Johnson Ham via cctalk wrote:

Thanks for that, but unfortunately it is crashing into ODT and not
accepting input from the console, which I remember was a symptom of no
bank 0 memory.

Now,of course, it could be the receiver chip in the J board (I used to
make a lot of money changing them ) but I have tried two separate J boards.

Of course if it is 4 MB, it must be in bank zero.

cheers,

Nigel


Can you read any of the CSR registers built into the serial board or cpu 
without the memory card inserted?   I don't believe ODT is dependent on 
working memory.

Re: Looking for info on memory

[Jerry Weiss via cctalk]

On 10/20/21 12:27 PM, Douglas Taylor via cctech wrote:

On 10/19/2021 12:57 PM, Nigel Johnson Ham via cctech wrote:

I am trying to bring up an 11/23 system in a BA23 box, and the only
memory i have is an obscure Plessey one. The only identification is the
p/n 705920 with dash-100 in white ink. By counting the chips I make it
4MB, but it does not respond. Since it takes the full 22-bit memory
space I can't see how any jumpers would change its accessibility. Does
anybody have a manual?

any help appreciated,

Nigel Johnson

Looking at the photo I began to wonder if Plessey made their own 
boards or are they re-badged from some other manufacturer.   I don't 
know.  If they are made by someone else, you might be able to dig up a 
manual.


Also, if you look at the documentation for other 4MB qbus memories how 
many jumpers do they have?  And what do they do?  It may help you 
understand your board.


Doug  (of course I don't have a 4MB qbus memory, but that apparently 
didn't stop me from posting.)


Looking at the silk screening, there is a Plessey logo so this is mostly 
likely there own design.   Given the date on warranty I would expect 
jumpers for 18/22 bus type, perhaps battery backup, parity CSR, memory 
chip size, I/O page size,etc...   But assuming the jumpers for memory 
address start and length are in some functional configuration, you 
should to poke/read ODT somewhere in the 4MByte addressing range.   You 
might also try to see you can read  default parity CSR for memory 
boards. The logic (and some circuity) for I/O page should be different 
than memory decoding.
Suggest you obtain a another memory board (e.g. M8044) to verify the 
other components.



Jerry

Re: PDP-11/05 Fault?

[Jerry Weiss via cctalk]

On 9/30/21 8:12 AM, Paul Koning via cctalk wrote:



On Sep 30, 2021, at 1:02 AM, Nigel Williams  
wrote:

On Thu, Sep 30, 2021 at 10:49 AM Paul Koning via cctalk
 wrote:

I see that the PDP-11 architecture handbook doesn't seem to be on Bitsavers...

Do you mean this handbook?

http://wwcm.synology.me/pdf/EB-23657-18%20PDP-11%20Architecture%20Handbook.pdf

ORDER CODE: EB-23657-18

(from here: http://wwcm.synology.me/scanned.html)

Yes, that's the one.  Excellent reference, it's the only place where I've seen 
that entire large tables (52 entries) of model differences.

paul



The same table is also in EK-DCJ11-UG-PRE_J11ug_Oct83.pdf.  I find the 
latter just a bit easier to read.


   Jerry

Re: SCSI2SD in a DEC 3000/300 - T-ERR-SCSI A

[Jerry Weiss via cctalk]

On 9/26/21 4:04 PM, Alexander Jacocks via cctalk wrote:

On Sep 26, 2021, at 10:03 AM, Bill Degnan via cctalk  
wrote:

I was either sacrifice a data drive to make it a backup of the primary or
find a like drive first, get the system stable and then upgrade.  I have a
3000 too here if you want to work together to troubleshoot yours

Bill


On Sun, Sep 26, 2021, 9:46 AM Zane Healy via cctalk 
wrote:


On Sep 26, 2021, at 12:22 AM, Alexander Jacocks via cctalk <
cctalk@classiccmp.org> wrote:

I’ve got a DEC 3000/300 system that has some SCSI drives with aging

bearings installed. I’d like to be able to start to migrate some of my
systems, like this, to flash media, of some kind, as even my large
repository of SCSI disks is starting to dry up.

Here is my SRM level info:
   DEC 3000 - M300
Digital Equipment Corporation
VPP PAL V5.56-80800101/OSF PAL V1.45-80800201 - Built on 30-SEP-1996

09:18:31.84

As far as I have read, the SCSI2SD v6 2020 should be compatible with

several varieties of DEC hardware, from the VAXen to the Alphas. However, I
can’t seem to get anywhere useful with mine. I have the virtual disks
configured as follows:

sh dev

BOOTDEV  ADDR  DEVTYPENUMBYTES RM/FXWPDEVNAM

  REV

---    --- -----

  ---

ESA0 08-00-2B-3F-4C-9A , TENBT
DKA100   A/1/0 DISK 9.54GB  FXRZ40

   6.0

DKA300   A/3/0 DISK 9.54GB  FXRZ40

   6.0

DKA400   A/4/0 RODISK 305.01MB  RM  WPRRD45

6.0

All three disks are from the SCSI2SD. I have attempted to make the

inquiry strings match the originals, as closely as possible. In the SCSI2SD
utility, I have the following config:

General page: all defaults, termination off (I have tried parity, scsi2

mode, and setting SCSI speed to sync, with no improvement)

Device 1: enabled, ID 1, device Hard Drive, start sector 0, sector size

512, sector count 18636800, vendor “DEC ", product “RZ40 “,
revision “ 6.0”, serial number 

Device 2: enabled, ID 3, device Hard Drive, start sector 18636800,

sector size 512, sector count 18636800, vendor “DEC ", product “RZ40
“, revision “ 6.0”, serial number 

Device 3: enabled, ID 4, device CDROM, start sector 37273600, sector

size 2048, sector count 148933, vendor “DEC ", product “RRD45“,
revision “ 6.0”, serial number 

I’ve also tried booting from a virtual CDROM, only, with no luck there,

either. In all cases, I get the following from SRM:

test scsi

T-STS-SCSI A - Data Trans test
? T-ERR-SCSI A - Data Trans test - nondma/sync inq size miscompare
T-ERR-SCSI A - id = 1 lun = 0

? T-ERR-SCSI A - Data Trans test - nondma/sync inq size miscompare
T-ERR-SCSI A - id = 3 lun = 0

? T-ERR-SCSI A - Data Trans test - nondma/sync inq size miscompare
T-ERR-SCSI A - id = 4 lun = 0
?? 002  SCSI 0x0008


84 FAIL

Does anyone have an idea what might be causing this? Has anyone tried a

v6 SCSI2SD in a DEC 3000?

Thanks!
- Alex

I picked up a couple v6 boards for my AlphaStation 200 4/233, but haven’t
tried to use them yet.

Are you using the onboard SCSI, or a SCSI board?  I’m ‘going to assume
you’ve tried a different cable, and to get it working from actual physical
drives?  Have you tried turning the termination on, on the board?  Is your
SCSI Bus Terminated?

You actually have RZ40’s in the system?  I’m asking as I’m not actually
familiar with that drive type, at least it’s not one I remember off the top
fo my head.  I usually use RZ29’s.  On my v5.2 board on my VAXstation
4000/90 I think I went with basic 8GB drives, without a vendor string or
product string.

I have a Quantum XP2160 and a Seagate 1050 in my 3000. Both function, but have 
significant bearing whine, and I have no idea how many hours are on each. So, I 
know my scsi subsystem and termination are fine. I’m going to pull a scsi2sd 
v5.2 from a Quadra 700 and try that, to see if I get the same errors.

I used the RZ40 as the inquiry string, and matched the sector count, to make 
SRM happy. I have real RZ25s and RZ26es, but they are quite small. Most of my 
modern scsi disks are 10 and 15k U320s, and not a good choice for heat 
constrained enclosures like the 3000. Not to mention that 300gb is just silly 
for Digital UNIX.

- Alex


Difference in length of data sent or expected for SCSI-1 vs SCSI-2 inq 
commands?


  Jerry

Re: WordPerfect for VMS

[Jerry Weiss via cctalk]

On 5/7/21 8:45 PM, Zane Healy via cctalk wrote:

Strange question, does anyone happen to have the keyboard overlays for the 
VAX/VMS version of Word Perfect that they can photograph, or better yet scan?  
I have the manuals, and the green, red, and blue stickers on the VT keyboard, 
but no overlays.  I *might* have the overlays, but I can’t find the the VT 
keyboard I’m thinking of (though after digging, I know I have more than I 
thought).

I’m looking for the VT200/300 version (which should work for my LK401).

Zane



If I had gone searching for it, I would have never found it.  As luck 
would have it, one just appeared while I was scrounging other things.


Scan sent via pm.


   Jerry

Re: RSX11D disks on EBAY- anyone interested?

[Jerry Weiss via cctalk]

On 4/8/21 4:48 PM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > I always wondered why the RKV11-D was only 16 bit addressable.

The manual (EK-RKV11-OP-001) says: "Since the 11/03 BUS structure has no
provision for extended addressing, no connection is made to the bus from
these [XM] bits on the RKVII-D." (pg. 3-5).


Certainly the published interface is constrained by what was 
"officially" released.   Just pondering if there was an internal 
engineering roadmap from 16->18->22 bits around this time or did things 
evolve more discretely?

 > The DEC RK05 disk subsystem cost $10K list circa 1978 (drive, RKV-11D
 > controller and cabinet), so this wasn't a trivial purchase.

Interesting. Where did you see that listed, just out of curiosity? (I looked
in the Jan '84 PDP-11 Systems and Options, my copy of which just showed up,but
that's too late; I could probably find it if I pawed through all my DEC sales
literature, but I'm too lazy... :-).

Noel



My reference here is "A source handbook for Digital Equipment 
Corporation LSI-l I-compatible products"

https://link.springer.com/content/pdf/10.3758/BF03205335.pdf

  Jerry

Re: RSX11D disks on EBAY- anyone interested?

[Jerry Weiss via cctalk]

On 4/7/21 1:23 PM, Noel Chiappa via cctalk wrote:

.

(Interestingly, the Dilog card above claims to the RKV11 compatible; but also
says it has "memory addressing capability" to 256KB. They can't both be true,
though; although the RKV11-D has the A16/A18 bits in the CSR, they aren't
connected to anything! See EK-RKV11-OP-001, pg. 3-5.)

Noel


Perhaps the marketing assumption is that if you are compatible with 16 
bit addressing, you don't even bother to check for 18 bit 
functionality.  I always wondered why the RKV11-D was only 16 bit 
addressable.  In those early days of the QBUS, perhaps the evolution of 
the architecture wasn't as clear.  Or was it an intention limitation?


The DEC RK05 disk subsystem cost $10K list circa 1978  (drive, RKV-11D  
controller and cabinet), so this wasn't a trivial purchase.


I used the the Dilog card (IIRC) with both the Diablo 31 and Dec RK05 
drives on LSI 11/23+ and 11/73's.  We had a cable that connected to the 
Diablo and then we daisy chained to the RK05.  We had to be careful 
since we were mixing 1 of N and decode N drive selection, but if you 
only had a few drives it was not too bad.


 Jerry

Re: TSX

[Jerry Weiss via cctalk]

This is probably TSX V6.2   There are copies of this version here - 
https://shop-pdp.net/~stuff/PDFs/TSX-Plus/


  Jerry

On 3/29/21 9:04 PM, Chris Zach via cctalk wrote:
Also came across a TSX Plus reference guide and install guide, from 
1985. These two fill a very large binder, have they already been scanned?


If not I'll burn out my scanner doing these. If so I can pulp or Ebay 
them.


C

Re: Modifying a RXV21 for an 11/83

[Jerry Weiss via cctalk]

On 1/24/21 8:11 PM, Chris Zach wrote:
Ok. My guess is it throws off the cache on the 11/73 and above as it 
works in an 11/23 (which is soo slow!).


I looked at the images, cut the traces, then soldered in two of the 
wires. Board did not work on either the 11/83 or the 11/23+ CPU. 
However when I looked closer I saw the tiny little wire down by the 
crystal and the Q bus fingers. Put that in, and the board now works on 
the 11/23+, will take the whole thing apart (again) and plug in the 
11/83.


Fortunately I have the pdp11/83 configured with a Q bus memory board 
(2-4mb) and a PMI memory board from an 11/84 placed in slot 2 (so the 
11/83 will access it as Q Bus memory). Thus I could pull the 11/83 CPU 
in slot 1 and pop the 11/23+ in. Aside from the exceptionally slower 
speed and long boot times it works pretty well for testing.


Still need to get a 11/83 compatible PMI board, but the 11/84 ones 
work as normal Q bus memory.


Thanks! Now I can read some of these RX02 disks and image them. I'm 
guessing my BRU floppy that I generated with the RXV11 controller will 
not boot on this RXV21 controller so I'll have to re-make that. And so 
far it doesn't look like the disks made on that third party MXV21 
controller are compatible with the RX02, should they be?


Chris


Congrats!

Most of the third party controllers and drives are OS compatible with 
the RX01 + RX02 format, provided you stick with Single Sided media.  
However, booting an OS with an RX01 controller handler (Interrupt 
driven) will not succeed with an RX02 controller (DMA) or vice-versa.


The Double Sided media (RX03) make for interesting interchange stories. 
I've seen double sided single density floppies. There are also 
differences in how the controller vendors made disk handler 
modifications for RT11.   Many of these controllers would allow you to 
perform a low level format, but only using vendor specific controller 
commands.   The DEC RX02 will only change the funky media density.


Remember that these are 18 bit controllers.   Some operation systems can 
work around this limitation, at the expense of CPU cycles.


  Jerry

Re: Modifying a RXV21 for an 11/83

[Jerry Weiss via cctalk]

On 1/24/21 11:27 AM, Chris Zach via cctalk wrote:
So I found an RXV21 board in the pile of stuff here and popped it into 
my 83. Crashes the system. It's an M8029 D board, and I see from this 
site that you have to add a few traces and cut a few others to make it 
work on an 11/73 or better.


http://www.chdickman.com/rx02/

I'll pop in an 11/23+ CPU just to test it, but is it really just 
putting in two wires on the top of the board and cutting a total of 
three traces? Looks simple enough...


C


My M8029 stamped Rev F  has three jumpers and three trace cuts. It 
matches the images posted in the link and works with an 11/73 ot 11/83. 
But yes, it should be that simple.


There is a sharpied H on my card, which it is not the way DEC marked 
these boards. The available field maintenance prints refer to this (no 
G).  I don't know what the change was.


   Jerry

Re: Regional accents and dialects (Was: The best hard drives??

[Jerry Weiss via cctalk]

On 11/19/20 4:06 PM, Fred Cisin via cctalk wrote:



Long Island (NY) was pronounced Lawn-GUY-land




The current Long Island accent developed in the mid to late 80's. 
Most of us living there before that had Bronx or Brooklyn accents...


I remember some of my friends would type on a ASR-33 with different 
accents as well

Re: Next project: 11/24. Does it need memory?--Memory sad!

[Jerry Weiss via cctalk]

On 10/26/20 8:31 PM, Chris Zach via cctalk wrote:
Ok, so I'm now troubleshooting the memory parity errors in the MS11-L 
memory. And yes, there are bit errors in the memory. I wrote a simple 
program to check the first 64k bank and I've found errors in bit 2 but 
not everywhere but on a predictable pattern of addresses. Interesting, 
possible that one of the address drivers is shot in that particular 
chip..


Checking the board I can see that most of the chips are ITT chips, 21 
16935 01. However I can also see that this is not this board's first 
rodeo, as several chips have been replaced with ITT chips 8411x 21 
14897 01 models.


Is there an equiv model for these chips that can be found? Looks like 
a 16k*1 16 pin MOS ram chip with +12,+5,and -5 voltages (wow!). I 
guess if they can't be found I can pull chips from the parity section 
and just ignore parity but I'd prefer not to desolder/resolder chips.


As they say, it ain't gonna fix itself so I might as well get going on 
it. ;-)


CZ


I have used this site to help me determine substitutes for memory chips 
- http://www.minuszerodegrees.net/memory/ram.htm


  Jerry

Re: Next project: 11/24. Does it need memory?--Working-ish!

[Jerry Weiss via cctalk]

On 10/25/20 8:01 PM, Chris Zach via cctalk wrote:

.
Question: Can an RX02 boot an RX01 floppy formatted single density 
with the DY: driver? Can it read an RX02 floppy in one drive and an 
RX01 floppy in the other or do you have to set the switches and use 
the right controller card (that would be stupid, but so DEC!)


Thanks everyone here and on the Discord for the help Getting there bit 
by bit.



Well done on sorting this out.  As to the RX02 questions

An RX02 drive in RX02 mode can read either DEC single or double density 
media in either drive.


If the RX01 media has a DY handler (RT11) configured as primary boot, it 
"may" be possible.  It will definitely not work with the DX handler 
configured.   To do this, you also need a different ODT/ROM bootstrap. I 
have pulled one I have in my files and pasted it below. I do not 
remember the source, but looks like someone has tried this before.




   Jerry

RX02 Single Density Bootstrap

Address    Contents
001000    012700
001002    100240
001004    012701
001006    177170
001010    005002
001012    012705
001014    000100
001016    012704
001020    000401
001022    012703
001024    177172
001026    030011
001030    001776
001032    100437
001034    012711
001036    07
001040    030011
001042    001776
001044    100432
001046    110413
001050    000304
001052    030011
001054    001776
001056    110413
001060    000304
001062    030011
001064    001776
001066    100421
001070    012711
001072    03
001074    030011
001076    001776
001100    100414
001102    010513
001104    030011
001106    001776
001110    100410
001112    010213
001114    060502
001116    060502
001120    122424
001122    120427
001124    07
001126    003735
001130    012700
001132    00
001134    005007
001136    00

Re: DEC ADV11-D Analog to Digital converter with DMA

[Jerry Weiss via cctalk]

Thanks, I had wondered if some the earlier ADV-11and AAV-11 boards were 
just re-branded DTI boards. I have been hoping this is true for the -D 
variants.


The most likely candidates are the DT2784/DT2782 and DT2771. Now if I 
can just find manuals for these...


    Jerry

On 10/17/20 2:06 AM, Paul Anderson wrote:

I think they were made by Data Translation.

On Fri, Oct 16, 2020 at 8:00 PM Jerry Weiss via cctech 
mailto:cct...@classiccmp.org>> wrote:


On 10/16/20 5:34 PM, Mark Matlock via cctech wrote:
>     I recently acquired an ADV11-D Qbus A/D board and having
been working on a RSX11M+ driver for it. It is similar enough to
the ADV11-C that the driver I wrote for the -C works ok, but the
-D is DMA capable.
>
>      It seems to have two extra CSR registers in addition to the
CSR, and read buffer. Does anyone have documentation for this
board? It is mentioned in the Oct. 88 Microsystems Option Guide
and both RSX and VMS supported it. It was also mentioned in the
Dec 92 Real Time Products Technical manual.
>
>    It has a 40 pin IDC connector that appears to have some
amount of differences from the ADV11-C and no where have I seen
any info on the DMA capability.
>
>     Does anyone have a ADV11-D user manual or XXDP source code
for testing it?
>
> Thanks,
> Mark

I just picked a AAV11-D D/A Board for which documentation is also
scarce. The general design may be similar.  I should be able to
reverse
engineer the analog/digital output section for pin-outs. Lacking
manuals/source code, if someone has an existing driver or software in
binary, I would be willing to disassemble that for its secrets. 
Perhaps
these boards mimic the methods used by ADAC or Data Translation
used for
their Qbus products.  Their documentation may also give some
insight on
how to setup these CSR's.

Regards,
Jerry

Re: DEC ADV11-D Analog to Digital converter with DMA

[Jerry Weiss via cctalk]

On 10/16/20 5:34 PM, Mark Matlock via cctech wrote:

I recently acquired an ADV11-D Qbus A/D board and having been working on a 
RSX11M+ driver for it. It is similar enough to the ADV11-C that the driver I 
wrote for the -C works ok, but the -D is DMA capable.

 It seems to have two extra CSR registers in addition to the CSR, and read 
buffer. Does anyone have documentation for this board? It is mentioned in the 
Oct. 88 Microsystems Option Guide and both RSX and VMS supported it. It was 
also mentioned in the Dec 92 Real Time Products Technical manual.

   It has a 40 pin IDC connector that appears to have some amount of 
differences from the ADV11-C and no where have I seen any info on the DMA 
capability.

Does anyone have a ADV11-D user manual or XXDP source code for testing it?

Thanks,
Mark


I just picked a AAV11-D D/A Board for which documentation is also 
scarce. The general design may be similar.  I should be able to reverse 
engineer the analog/digital output section for pin-outs. Lacking 
manuals/source code, if someone has an existing driver or software in 
binary, I would be willing to disassemble that for its secrets.  Perhaps 
these boards mimic the methods used by ADAC or Data Translation used for 
their Qbus products.  Their documentation may also give some insight on 
how to setup these CSR's.


Regards,
Jerry

Re: RK11-D "diskless" test ZRKJE0???

[Jerry Weiss via cctalk]

On 7/9/20 7:02 PM, Robert Armstrong via cctech wrote:
  I have an 11/04 with an RK11-D.  I have a couple of RK05s, but I 
wanted to test the controller before I start working on the drives.  
The PDP11 Diagnostic Handbook says that ZRKJ?? "checks only the 
drive-independent logic of the RK11 controller. no drive is 
needed..."  I assumed that meant it was a diskless test, but now I'm 
not sure that's true.  Can anyone confirm or deny this? Does anyone 
have a listing of ZRKJE0?


See 
http://bitsavers.org/pdf/dec/pdp11/microfiche/ftp.j-hoppe.de/bw/gh/EP-DZRKJ-E-DL-A__RK11-05F-J__RK11_BASE_LOGIC_TEST_1__MD-11-DZRKJ-E__(C)75-77.pdf




  I'm starting to wonder if this diagnostic really works w/o a drive 
attached, or if these errors are expected.



Yes.. it only requires the controller.  See the notes in the listing.


   Jerry

Re: Got the RX01's running and TSX

[Jerry Weiss via cctalk]

I have run TSX+ since the early 80's.    I developed a few handlers to 
do graphics on a Peritek VRG-Q  and also for data acquisition.


Nothing like like an  J-11, 4Mb and a hard disk to make a excellent 
personal workstation back then.   RXV21's were not a problem as TSX+ 
(>v6 I think) could automatically low buffer for them as required.


    Jerry

On 4/28/20 7:39 PM, Chris Zach via cctalk wrote:
So I got the RX02 drive up and going with the RXV11 controller. Man 
it's interesting to hear those old disks *click*. Both work (which is 
good) and now I'm starting to look through my old disks.


Interesting issue: Many of my disks are formatted RX02. So I need to 
dig out my RXV21 controller from some box around here and see if that 
works. I never liked the RXV21: It's only 18 bits, does DMA, and is 
quite weird in a 4mb pdp11. But I would like to get this data off.


I also uncovered my old TSX disks. I have TSX+ 6.5, 6.4, and TSX 
5.something here on double sided RX02 disks. Looks like my support 
contract ran out in 1991, I'll have to see about renewing that


Anyone here still running TSX, or did everyone go to RSX11M+?

C

Re: pdp11/84 PMI memory: What is the problem with Q bus?

[Jerry Weiss via cctalk]

Sorry about the uNOTE confusion...  I was focused and just used the 
reference from the OEM version.  I was aware but had mentally excluded 
the older Microcomputer Products Group/Components Group version.


If you look at the Memory Comparison table in this OEM uNOTE, it only 
lists Block Mode for "JD/JE ONLY".  Hence my comment about it not being 
on the JB/JC.


   Jerry

On 4/24/20 11:23 AM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > uNOTE # 028 indicates that MSV-11 JB/JC (M8637-B/C) doesn't do block
 > mode.

I went and looked at uNOTE #28, after I found it (it's not in the initial set
of uNOTEs, but in the second set - the so-called 'OEM uNOTEs"; note that the
numbers were re-used between the two sets, so there are _two different_ uNOTE
#28's).

I couldn't find anything there about the JB/JC not doing block mode? All it
says is they "can not be used in a Q-BUS system due to gate array
incompatibilities".

Noel

Re: pdp11/84 PMI memory: What is the problem with Q bus?

[Jerry Weiss via cctalk]

On 4/19/20 2:29 PM, Chris Zach via cctalk wrote:
So I picked up an 11/84 CPU, 3mb of memory, and a 11/84 Unibus card on 
Ebay. Goal is to speed up my fastest 11 here


For boot time, the diagnostics run in 13 seconds (from when it starts 
to prompt) on the 11/73 board I have and 13 seconds on the 11/84 
board. This is with a camintonn 2mb half height memory board.


Put in the first PMI module above the 11/84 CPU and tried it out. This 
is a CA rev board which apparently only works in a Unibus pdp11 and 
not a Q-bus one. Apparently it does work.


So what exactly was the bug with the older PMI memory? Block mode DMA, 
I'm using an MTI ESDI controller which can do 16 word block DMA on Q 
Bus. Something else


EK-MSV1J-UG 001 documents the the versions that don't do Q-Bus Cycles.  
uNOTE # 028 indicates that MSV-11 JB/JC (M8637-B/C) doesn't do block 
mode. I suspect the MTI card  falls back to single cycle DMA. Also RT11 
simply may not challenge the configuration sufficiently to demonstrate 
the limitations of the -CA memory variant.



I have not seen any document that describes this as a "bug", so it must 
be a "feature"  /s




  Jerry

Re: DEC QBUS Backplanes

[Jerry Weiss via cctalk]

We had a few third party backplanes arranged like this.  This allowed 
them to put a small MFM hard drive or 8 inch floppy in empty  area next 
to the 4x2 (2x4?) slots of rack-mount 3U or 4U sized unit.  I don't 
recall any that were a mix of A-B, C-D.  Ours were A-B, A-B.


    Jerry

On 4/17/20 8:48 PM, Nigel Johnson via cctalk wrote:
The actual sockets were always labelled with Digital's trademarks, but 
they sold them to OEMs to do what they like with them.  We OEM'd for 
the Components Group, at one time placed a million dollar order of 
stuff including boxes of those backplane sockets!


cheers,

Nigel



On 17/04/2020 21:40, Paul Anderson via cctalk wrote:

I remember the VT72 had a non-standard backplane in it, but I don't
remember the details.

Paul

On Fri, Apr 17, 2020 at 8:10 PM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:


On 4/17/20 8:36 PM, Chris Zach via cctalk wrote:

Hm. Plessy backplane?

No name on the phenolic board part but the QBUS sockets are labeled
"Digital Equipment Corporation".

bill

Re: Previous message: Wire list for the RKV11-D Qbus RK05 controller backplane anywhere?

[Jerry Weiss via cctalk]

On 2/12/20 11:28 AM, Noel Chiappa via cctalk wrote:

 > From: Jay Jaeger

 > Yeah, info does seem to be scarce.  Not even in my LEVAX fiche set.

My fiche set has the Technical Manual, and also (in the wirelist
section) the wirelist.

Not sure how to get it to you, though. I stuck it in my industrial-grade
scanner at its highest resolution; no go. I suppose I could take photos
of it displayed on my fiche reader?

Or is there some device I can buy which is less than a zillion dollars which
can scan fiche? There are a number of things in my set (e.g. the BA11-N Tech
Manual) which aren't online, and would be useful to have.

 > That fourth card (M7268) is apparently a connector card for the Q-Bus
 > and drive bus.

Yes, but actually there are 6 cards: the M7269 is a dual card which goes
into the QBUS backplane, and the M993-YA which goes into the first RK05,
to convert from the two flat cables which come from the M7268.

 > From: Al Kossow

 > Also, it is only 18 bits.

Actually, only 16-bit DMA addresses, I'm pretty sure.

Noel
That's what is documented in Micronote #5. There is a comment in the 
15-Dec-1994 DECUServe Journal that says it can be modified for 18 bits 
from Alan Frisbie.


    Jerry

Re: AED WINC08

[Jerry Weiss via cctalk]

On 11/11/19 12:27 AM, Eric Moore via cctech wrote:

Hello, I have a working AED WINC08 drive, which is a winchester drive
emulated to look like an RL02, along with the qbus controller card.

https://archive.org/details/bitsavers_aedbrochurJan82_2107642/page/n1

The winchester drive itself is a fujitsu M2302B. One of the disks (it shows
up as 2 10MB volumes in RT-11) is having write issues. How can I find a
replacement disk drive in working order? The 2302b has a shugart compatible
interface, so should any shugart compatible 8" winchester drive work in the
aed winc08 rl02 emulator?

What other options do I have to attach a winchester drive to an 11/03 for
use in rt-11? I have an RL02 I have never hooked up, do the disk packs hold
up well over time? How hard is it to clean and align an 8" winchester drive
to try and address the write issue?

Thank you,

-Eric


In my (pre) historic use of products similar to this one, it was rare to swap 
the vendors drive with a completely different drive. The controllers, their 
electrical interfaces and recording formats were tightly coupled to the disk 
drives implemented.

My suggestion would be to look for a QBus SCSI Controller like the Emulex UC07 
or  Dilog SQ739, though both are a bit pricey.   These open up a large number 
of drives to use and later versions of RT11 support the MSCP protocol the 
controllers emulate.  The use of the SCSI2SD drive emulator gives even more 
flexibility through the use of microSD cards.  Google around for both.

I have an pair of RL02 drives.  I keep them clean and power them up for short 
periods regularly.  You need to be alert to potential issues with electrolytic 
capacitors drying out and causing problems in the power supplies and circuit 
boards of all devices of from this era.  See 
http://www.vcfed.org/forum/showthread.php?72247-Dismantle-an-RL02-pack for a 
recent discussion  and pictures of some of the material in the packs decaying 
over time.

Jerry

Re: Looking for schematics of QBUS 32KW memory module.

[Jerry Weiss via cctalk]

On 9/8/19 4:21 PM, Mister PDP via cctalk wrote:

I guess I should have been a little more specific about the memory issues I
was having when I made this post. For the most part these issues seem to be
scattered all about memory. Also, while the XXDP I have been running has
been catching more or less the same addresses every time I run it, someones
it misses a few or adds a few new ones. Moreover when the tests are done, I
can read and write to the addresses using OTD just fine, which makes me
think the chips that are bad (if they are bad, and it isn't some power
related issue) are more flaky than dead.

I put one of the outputs from a run of the XXDP test on a pastebin below.

https://pastebin.com/mF6qWs0U


If the voltage to these chips is not stable or at the correct voltages, 
the circuitry to refresh the dynamic memory might fail or read the wrong 
data level from the memory cells.   Some chips may be more sensitive to 
slightly out of spec voltages than others.  There of course may be a 
pattern in the outputs that suggest that have one or many bad memory 
chips, but I haven't zero'ed in on it yet.


I have the same floppy controller sitting on project list for later in 
the year, so keep us posted as to your progress.


Jerry

Re: Looking for schematics of QBUS 32KW memory module.

[Jerry Weiss via cctalk]

On 9/8/19 3:20 PM, Noel Chiappa via cctalk wrote:

 > From: Mister PDP

 > listed back there were numerous bad addresses all over memory.
 > ...
 > I cannot find schematics for any of the boards

.

With the completed chart in hand, given a failing word (address and bad
data), you can work out which chip is at fault, and replace it. Repeat
for all memory errors.



Noel's approach is valid and I have done the same on several boards.  
Sorry I don't recognize the vendor of your board.


I would also suggest checking the voltages on the board, especially the 
-5V for the memory chip if the memory faults are scattered across the 
memory space. The circuitry on the upper left of your picture is 
probably a NE555 that is used as a charge pump to generate Vbb from the 
LSI power supplies.


The larger capacitors are probably tantalum (Kemet?) and should have 
aged better than electrolytics of the period.


  Jerry

Re: XXDP on PDP-11/03

[Jerry Weiss via cctalk]

There are two versions of XXDP+ V2 monitors.   The XXDPSM.SYS is needed 
for cpu's w/o MMU's or don't have more than 28KW.  This and XXDPXM.SYS 
are both on the AK6DN diagnostic image. However, only a few other 
programs exist on the image.


In SIMH the AK6DN image does the same thing.  The halt location 100 is 
near the LTC vector.  I turned BEVENT off and it boots successfully.

I am not immediately sure why this is necessary.


sim> show cpu
CPU    11/03, NOEIS, NOFIS, BEVENT disabled, autoconfiguration enabled, 
idle disabled

    56KB
sim> show ry
RY    address=1170-1173, vector=264, BR5, 2 units
  RY0    512KB, attached to XXDP.RX2, write enabled
    double density
  RY1    512KB, not attached, write enabled
    double density
sim> boot ry


MEMORY MANAGEMENT UNIT NOT FOUND
BOOTING UP XXDP-SM SMALL MONITOR

XXDP-SM SMALL MONITOR - XXDP V2.6
REVISION: E0
BOOTED FROM DY0
28KW OF MEMORY
NON-UNIBUS SYSTEM

RESTART ADDRESS: 152010
TYPE "H" FOR HELP

.H
? NOT FOUND: HELP  .TXT



From a XXDPXM boot.

.DIR

ENTRY# FILNAM.EXT    DATE  LENGTH  START   VERSION

    1  XXDPXM.SYS   1-MAR-89 39    67   F.0
    2  XXDPSM.SYS   1-MAR-89 29    000136   E.0
    3  DRSXM .SYS   1-MAR-89 48    000173   C.0
    4  DRSSM .SYS   1-MAR-89 24    000253   G.2
    5  DIR   .SYS   1-MAR-89  7    000303   D.0
    6  DB    .SYS   1-MAR-89  2    000312   C.0
    7  DD    .SYS   1-MAR-89  3    000314   D.0
    8  DL    .SYS   1-MAR-89  4    000317   D.0
    9  DM    .SYS   1-MAR-89  4    000323   C.0
   10  DR    .SYS   1-MAR-89  3    000327   C.0
   11  DU    .SYS   1-MAR-89  4    000332   E.0
   12  DY    .SYS   1-MAR-89  3    000336   D.0
   13  LP    .SYS   1-MAR-89  1    000341   B.0
   14  MM    .SYS   1-MAR-89  3    000342   C.0
   15  MS    .SYS   1-MAR-89  4    000345   C.0
   16  MU    .SYS   1-MAR-89  4    000351   E.0
   17  DATE  .SYS   1-MAR-89  2    000355   B.0
   18  DUSZ  .SYS   1-MAR-89  2    000357   C.0
   19  ZRXAF0.BIC   1-MAR-89 17    000361
   20  ZRXBF0.BIC   1-MAR-89 16    000402
   21  ZRXCA0.BIN   1-MAR-89  7    000422
   22  ZRXDC0.BIC   1-MAR-89 30    000431
   23  ZRXEA2.BIC   1-MAR-89 17    000467
   24  ZRXFB0.BIC   1-MAR-89 31    000510

FREE BLOCKS:   629


   Jerry




On 8/13/19 8:05 PM, Douglas Taylor via cctalk wrote:
Recently, I assembled one of the RX02 emulator boards developed by 
AK6DN. I am using it presently in a BA11-M box with PDP-11/2 cpu 
(really basic 16 bit system).  I put the disk images from github on 
the SD card (RT11 V5.07 and XXDP not sure what version).


The box has a BDV11 bootstrap / terminator board and I use this to 
boot the RX02 emulator.  Works fine when I boot RT11, however I can't 
boot XXDP - it halts at 000104.


Do I need to use a different version of XXDP to run on the PDP-11/03?

Doug

Re: OT: Reflowing GPUs and the fruit company (was Re: Resurrecting integrated circuits by cooking them.)

[Jerry Weiss via cctalk]

On 7/28/19 8:33 PM, Jay Jaeger via cctalk wrote:

On 7/28/2019 4:24 PM, Chuck Guzis via cctalk wrote:

On 7/28/19 1:02 PM, Jerry Weiss via cctalk wrote:

This method is not limited to "vintage" components.

My MacBook Pro 2011 fails dues to its (famous) problem with the discrete
AMD GPU connections.   A reflow restores the laptop, but inevitably I
have repeat the process every few months. Depending on who you believe,
the fault is with the A) poor thermal design, b) BGA solder used or C)
bumps on the AMD GPU itself.  The reflow is easy enough to do, but
disconnecting the very fragile cables to remove the motherboard is not
for everyone. Using an inexpensive infrared thermometer improves the the
process.


And of course, the solder is Pb-free...


--Chuck



Exactly.  And machines of that era had a lot of problems (I have
reflowed two early PS/3's a total of three times, and a MacBook) as
manufacturers climbed the learning curve.  The Microsoft XBox 360 "Red
Ring of Death" was another instance.


I sometimes wonder if I  leave the MBP in alone/unused for a year, 
whether it would heal itself by growing some "tin whiskers"

Re: Resurrecting integrated circuits by cooking them.

[Jerry Weiss via cctalk]

This method is not limited to "vintage" components.

My MacBook Pro 2011 fails dues to its (famous) problem with the discrete 
AMD GPU connections.   A reflow restores the laptop, but inevitably I 
have repeat the process every few months. Depending on who you believe, 
the fault is with the A) poor thermal design, b) BGA solder used or C) 
bumps on the AMD GPU itself.  The reflow is easy enough to do, but 
disconnecting the very fragile cables to remove the motherboard is not 
for everyone. Using an inexpensive infrared thermometer improves the the 
process.


    Jerry

On 7/27/19 3:50 PM, Jeffrey S. Worley via cctalk wrote:

On Wed, 2019-07-24 at 21:24 -0400, Pete Rittwage wrote:
I did some lookup on the reflow temperatures for various solder
materials because my gut told me 250 degrees is too low to do any good.
Turns out this is so.  250 CELCIUS maybe, but Fahrenheit? not.

  
https://www.google.com/search?q=melting+point+of+solder=isch=iu=1=lNlL1odJeOshrM%253A%252Cdl2_5Te6VgKpAM%252C_=1=AI4_-kRutgIaitoyNNmWoI_dbqyF1P0xmQ=X=2ahUKEwi17--3_NXjAhUK2FkKHZhiCaIQ9QEwAHoECAEQAw#imgrc=lNlL1odJeOshrM

:

Here's a link to that information.  It looks like 220 Celciums is about
right.  So if you were in Fahrenheit then that would explain the total
failure of the experiment and make it worth retrying.

RSVP

YHOSvt.

** TNM **


I tried this a year or two back with about 30 x SID, VIC, and PLA
chips
out of C64's. I heated them in the oven at about 250 for 15 minutes.
None of them showed any more signs of life than before I tried it,
unfortunately.

Re: 11/93 Rebuild - SCSI HD now boots RT11

[Jerry Weiss via cctalk]

On 5/31/19 1:04 PM, Rod Smallwood via cctalk wrote:

Hi

    Well I now have a bootable SCSI drive on my 11/93. Its not RSTS/E 
(yet) but it is RT 11 and reliable.


Its a bit baseline but it runs.

So next up was to see if we could get the RQDX3 to co-exist with the 
SCSI controller.


I switched the base address to 160336 and it does not stop the SCSI 
drive booting as DU0.


Had the RQDX3 been on the normal base address I think you would get 
the HD as DU0 and the two halves of an RX50 as the next two drives.


But what happens to the RX50's when you move the RQDX3 to 160336 ?

Rod



In RT11 the mapping of the controllers (port), drives (unit) and 
partitions is stored in the device handler of the disk you bootstrap 
from.  You can have customize different configurations on each of your 
SCSI drives and the RQDX3 HD.  You have to make sure that the disk being 
booted has a valid mapping for the SY disk on its handler (DU.SYS or 
DUX.SYS).  There are no checks on the "SET DU" commands to ensure the 
resulting configuration is bootable.


Check out the RT-11 Device Handlers Manual  (section 2.3 in the Aug91 
version).


  Jerry

Re: HP/UX 8 and hosts vs DNS

[Jerry Weiss via cctalk]

On 5/27/19 12:31 AM, Cameron Kaiser via cctalk wrote:

I'm not as adept at HP/UX before 10.20 (my first experience with the OS),
but I understand 8.0 "fails over" to /etc/hosts if it has some issues with
DNS. Fine, but how can I get it to switch *back*? There's no
/etc/nsswitch.conf and I don't think this version supports it anyway.

 From https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch06_04.htm

Before HP-UX 10.10, you could only use nsswitch.conf to configure the
order of resolution for the hosts source. From 10.10 on, you can also
use nsswitch.conf to configure resolution order for the services,
networks, protocols, rpc, and netgroup sources. hosts: dns
[NOTFOUND=return] nis [NOTFOUND=return] files"

Appreciated, but from the same resource,

"HP-UX 10.00 introduced Solaris's nsswitch.conf functionality"

so this won't apply to HP/UX 8.
It was available for in 9.x, but not at first first release.  It was 
introduced through patches.

I don't know if 8.x received the same/similar patches.

Re: HP/UX 8 and hosts vs DNS

[Jerry Weiss via cctalk]

From https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch06_04.htm


Before HP-UX 10.10, you could only use nsswitch.conf to configure the 
order of resolution for the hosts source. From 10.10 on, you can also 
use nsswitch.conf to configure resolution order for the services, 
networks, protocols, rpc, and netgroup sources. hosts: dns 
[NOTFOUND=return] nis [NOTFOUND=return] files"




On 5/26/19 11:09 PM, Cameron Kaiser via cctalk wrote:

I've been doing more work on my 9000/350 now that I have actual space to
do work on it in. Although the 10b2 is flaky, I can usually coax it to work.

However, the damn thing won't query DNS even though I have a populated
/etc/resolv.conf. It can ping the name server, and if the name server's
name is in /etc/hosts it will resolve it (and even telnet to it), but it
won't talk to it for anything else.

I'm not as adept at HP/UX before 10.20 (my first experience with the OS),
but I understand 8.0 "fails over" to /etc/hosts if it has some issues with
DNS. Fine, but how can I get it to switch *back*? There's no /etc/nsswitch.conf
and I don't think this version supports it anyway.

Re: SIMH question

[Jerry Weiss via cctalk]

On 4/24/19 10:14 AM, Paul Koning via cctalk wrote:
On Apr 24, 2019, at 11:05 AM, Noel Chiappa via cctalk 
 wrote:



From: Glen Slick
when I wanted to assemble some code with the RT-11 assembler but wanted
to edit the source code elsewhere and then transfer the code into a
SIMH disk image.

Someone should write the SIMH equivalent of Ersatz-11's 'DOS device' (which
allows the -11 access to the file system on the host - and also the ability
to send arbitrary commands to the emulator).

Alternatively, a newer PUTR.  I started such a thing as an extension to flx.py 
a while ago but only did a few small bits.


  For RT11 (and TSX+)  filesystem images I have used pyRT11 - 
https://gitlab.com/NF6X_Retrocomputing/pyRT11

Re: PDP-11/93 and PMI Memory

[Jerry Weiss via cctalk]

The second memory boards CSR should be viable in ODT.

The toggle switch internal contacts may be tarnished with age. Cycle 
each switch, that is used in the on position, multiple times and see if 
the CSR appears.
Try another CSR if necessary to confirm the memory board is responsive 
to Q-bus requests.


Which memory board and rev? MSV11-JE (M8637-E)?

Jerry


On 4/18/19 8:20 PM, Bill Gunshannon via cctalk wrote:

Well, I was finally able to get a PMI memory board to expand my
11/93 to the full 4 Meg.  (Thanks Paul!)

I thought it would be as simple as configuring what bank I wanted
it to fill and inserting it (in front of the CPU).  Sadly, that
didn't work.  First problem is the only document i could find is
not for the actual version of the board I  have.  It has the same
switch sets so I tried it anyway.  Set it to be in the upper 2Meg
and gave it the next CSR after the on board memory.  No luck.
11/93 still reports 1024KWords and the Map command shows neither
the additional memory or the second memory CSR.

Anybody have any experience with this? Is there a switch I have to
change on the CPU module to make it recognize the additional external
memory?  IS there something about PMI that I am missing?

Any advice gratefully appreciated.

bill

Re: SCSI2SD: Is it worth a try?

[Jerry Weiss via cctalk]

The system I use (OSX) to mange the SCSI2SD cards configuration and 
firmware doesn't have a SCSI.  I'd think of it more as a "nice to have" 
than a requirement.  The V6 cards allow data exchange via USB2.


If you have the appropriate images, you can just DD the data directly to 
the microSD cards on OSX and Linux.  I move and backup images for RT11,  
XXDP,  NeXT (Intel and 68K),  SunSparc, Linux and VMS this way.  The V5 
cards have shown themselves to be quite versatile in my shop.


   Jerry




On 3/20/19 10:37 AM, Douglas Taylor via cctalk wrote:

I've used the SCSI2SD with great success with vintage DEC computers.
On QBUS machines, both vax and pdp-11, it has worked with Emulex UC07, 
TD systems Viking, Andromeda SCDC and the DEC RQZX1 controllers.
I have used it on native SCSI controllers in VAX 3100, VLC 4000 and 64 
bit ALPHA machines.


The only other point I would make is that you need a linux system with 
a SCSI controller to move data in/out of the SCSI2SD.  I am using a 64 
bit Debian system and I found that the 32 bit SCSI2SD utility wouldn't 
run on the 64 bit machine and needed to be recompiled.  However, I 
still use a Windows 7 computer to setup the SCSI2Sd via USB.


Doug

On 3/18/2019 10:15 PM, Charles Dickman via cctalk wrote:

Re: PDP-11 disk image question

[Jerry Weiss via cctalk]

On 2/20/19 1:25 PM, Glen Slick via cctalk wrote:

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
 wrote:

Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.

I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.

I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.

..
Paul K's explanation and Glen's example matches my own experience in 
this area. I don't have a CMD controller, but I move images between SIMH 
and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used 
RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD 
emulated disks.


The physical SCSI drives I use have SCSI reassign capability. This 
allows the controller/drive to manage media defects.  This is 
transparent to any of the OS'es. The controller presents the disk simply 
as a continuous logical disk of disk blocks and the geometry has no 
effect.    Space reserved for bad block replacement is not visible to 
the OS.


I make sure the number of logical blocks is maintained exactly as I move 
the images back and forth between SIMH and physical Machines. The disk 
type RA90, RA81, etc never makes a difference.  The MSCP controllers 
read the media size directly and report the disk logical capacity to VMS 
Drivers.


If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then 
problems will occur.  For ODS type volumes, my understanding is that 
bitmap.sys file won't have room to manage the extra space.   I also try 
to avoid edge cases for disk sizing that involve powers of two - e.g. 
2**32.   In my general experience, I have found boundary check problems 
in different situations (especially non-Digital).



Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented
    device, shareable, error logging is enabled.

    Error count    0    Operations 
completed   2653
    Owner process ""    Owner UIC  
[SYSTEM]

    Owner process ID        Dev Prot S:RWPL,O:RWPL,G:R,W
    Reference count   48    Default buffer 
size 512
    Total blocks 7603200    Sectors per 
track    63
    Total cylinders  474    Tracks per 
cylinder 255


    Volume label  "VAXVMS73"    Relative volume 
number    0
    Cluster size   9    Transaction 
count   155
    Free blocks  3072564    Maximum files 
allowed    419336
    Extend quantity    5    Mount 
count   1

    Mount status  System    Cache name "_NASTY$DKA100:XQPCACHE"
    Extent cache size 64    Maximum blocks in extent 
cache   307256
    File ID cache size    64    Blocks currently in extent 
cache 307161
    Quota cache size   0    Maximum buffers in FCP 
cache    557
    Volume owner UIC    [SYSTEM]    Vol Prot 
S:RWCD,O:RWCD,G:RWCD,W:RWCD


  Volume Status:  ODS-2, subject to mount verification, protected 
subsystems

  enabled, file high-water marking, write-through caching enabled.


I don't see a discrepancy on SCSI2SD V5 cards between configuration size 
and VMS reported block,  The size used is recorded on the SCSI2SD V5 
card.  The SCSI2SD V6 adapters store the drive configuration on the last 
block of the microSD and I believe reported capacity is reduced by 1.   
Perhaps the CMD is doing similar to allow the media to be interchanged 
between controllers.


  Jerry

Re: PDP-11 disk image question

[Jerry Weiss via cctalk]

On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote:

So, I used SIMH to do an install of a complete OS on
an RA81 disk.  I would like to  move this to a real disk
and try it on a real PDP-11.  Is there a way to do this
using dd on a BSD machine?  I tried but it created a
non bootable system.  Well, actually, it starts to boot
but then fails very early in the startup process.  I used
"dd if=filename of=raw-device bs=1024".  Could it be that
the block size needs to be something else?

I know that VTServer and PDPGUI can move disk images but
it would take a week at 9600 baud and I think very little
likelihood of it ever completing successfully.

bill
As long as the media is presented as "Error Free", you should be able to 
to change the block size.   Since a RA81 (MSCP) remaps error blocks 
automatically and invisibly, it should work.  Is the media type the same 
on SIMH and Real PDP11?   If all else fails try bs=512.


For drives that have OS visible media defects, you should make sure the 
block size matches the same on the media and also use the option 
"conv=noerror,sync".  Otherwise dd will actually reorders the blocks(!), 
good first then zero fill the ones it cannot read.


    Jerry

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

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 both V6 Unix and RSTS/E V06C from disk.

*THAT* was a really fun and rewarding hunt :-)  First message in the thread was 
back on Dec 30, 2018.  Lots of debugging and failed DRAM repairs, then the 
final long assault to this single, failed gate...

Thanks to all here for the help and resources, and particular shout-outs for 
Noel and Paul who gave generously of their time and attention working through 
the densest bits, both on and off the list.

I predict a long happy weekend and a big power bill at the end of the month :-)

 cheers,
   --FritzM.



Congratulations.  Well Done.

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.


I'm trying to make sense of the M795 to get a better understanding. Any 
addition data on how the 7430 failed (input bad, output bad, etc ?)


  Jerry

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

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_ cross moby boundaries, so clearly it
has the right overflow output; someone just decided not to implement it - the
DR11-B sets ERROR instead on an address overflow. Wierd.
    Yes the overflow sets error and halts the transfer.  There are 
registers for the extended bits in the DR11B, just missing a few gates 
to increment.   My recollection is that my simple mod wouldn't allow the 
read back of the incremented extended bits, but in my use case this was 
never a problem.



Anyway, it will be interesting to see if RSTS operates correctly once this
problem is fixed...

Noel
  
Yes if turns out the increment was not functional for one or both 
extended address bits, it is impressive that UNIX booted successfully 
without tripping over a boundary.


  Jerry

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

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 multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.



OH, BOY!  I think you may have found it.  Likely some disk controllers did NOT 
SUPPORT crossing 64K boundaries!  The diags would not detect that, as it was 
likely expected behavior.  I would suspect the driver would need to break up 
these operations.

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 certainly isn't a restriction in the RK11.

paul

Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K 
boundaries.


I did however via a single chip "dead bug" modification, modify one to 
accomplish this.


    Jerry

Re: TU-58 support under Unix

[Jerry Weiss via cctalk]

My speculation would be that TU58 did not add anything of value or 
convenience to these systems.


I used Ultrix-11, V7M, Venix in this era.  My recollection is that in 
most cases to build these systems and patch them, you needed regular 
access  to 800/1600 BPI tape. Given this relatively standard media, the 
addition of a smaller, slower, proprietary secondary tape media would at 
best be a low priority.    Throw in the raise of floppy media, then 
Ethernet, it becomes even less so.  Also this was a fixed block type 
device, so any use between different OS's would have required additional 
utilities and/or OS support to transfer files.


We had TU58's in our VAX 11/750  and few computerized medical systems.  
Only on the later did we ever use them to move data on a regular basis.  
This was for research purposes as vendor had not made any other 
arrangements for data offloading.  The TU58's were in a small 
semi-portable cabinet.  Thus they could be added and removed quickly w/o 
altering the qualification of the medical device.


 Jerry



On 2/3/19 1:13 PM, Bill Gunshannon via cctalk wrote:

Here's a question for someone who has been around long enough to
remember.

Why did none of the available PDP-11 Unixes support the TU-58?
I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9
but I suspect if it isn't in 2.11 it wasn't in 2.9) and none
of them had support for the TU-58.  Seems to me it would have
been a rather simple device to handle as it ran over a serial
line.

bill

Re: advice / suggestion wanted PDP 11/40 only boots XXDP, not RT11

[Jerry Weiss via cctalk]

My recollection is that XXDP tries not to use Interrupts or DMA, unless 
it has to.


I would check out those areas first for problems if it hangs in RT-11.

Jerry


On 1/31/19 2:26 PM, Bill Degnan via cctech wrote:

My PDP 11/40 suddenly lost it's ability to boot RL02 disks except the XXDP
disk.  I have two drives, both boot up an XXDP (I have more than one) just
fine, but any formerly-working RT-11 (v 5, 5.1, 5.3) no longer boots, it
just hangs.  I have been troubleshooting, running the 11/40 XXDP tests, but
they seem to just hang too. And I am not a big fan of XXDP anyway.  I have
cleaned the drive heads, the disks are ok.  I can load BASIC just fine from
PDPGUI "tape" through the serial card (M7800)

Any off the cuff suggestions why this specific issue would arise?   Power
seems ok, looking for dumb reasons that I missed.  I have swapped out CPU
cards, does not make any difference.  I am pretty sure it's a UNIBUS
interference issue, at least that's my working theory.  I suppose there may
be an RT-11 boot instruction call or routine of the CPU that XXDP does not
exercise explaining why XXDP boots.Maybe RAM locations.

In the end I just have to work through everything, but I am open to
suggestions to help cut down the time spent diagnosing the problem.

Thanks in advance, I will be around tonight (East Coast USA Time)

Bill

Re: PDP-11 Memory

[Jerry Weiss via cctalk]

On 1/12/19 11:39 AM, Bill Gunshannon via cctalk wrote:

On 1/12/19 12:29 PM, Pete Turnbull via cctalk wrote:

On 12/01/2019 01:24, Zane Healy via cctalk wrote:


I’m pretty sure you could get the /23+, /53, /73, /83, and /93 in
either a BA23 or a BA123.  I have an actual badged BA23 pedestal for
my /23+.

I'm fairly certain all microPDP-11/23+ systems were only sold in BA23
boxes, and I think microPDP-11/73 and the later, cheaper, cut-down 11/53
were as well.  But almost all the 11/83 systems I've ever seen were in
BA123 boxes, though they did sell some in BA23 pedestals - I've got one.


One confusing part of this.  Everything I have read today
seems to say that the only difference between the 11/73
and the 11/83 in a MicroPDP-11 was the memory used.
QBUS = 11/73
PMI = 11/83

I use this guide in general - 
http://web.frainresearch.org:8080/projects/pdp-11/dcj11.php to 
understand the key differences in DEC DCJ11 implementations. You can see 
how the clock speed, caching and memory type drove differences in 
performance and marketing labels.


The 11/83 (M8190-AD or AE) with Non-PMI memory is just a slow 11/83 in 
my view. I know RT11 did report it as an 11/73.   It could be that from 
a software perspective, RT11 might not be possible to determine the 
actual module in use.


Does the 2MB 11/93 not work with and extra 2Mb of QBUS Non-PMI memory?  
I would have thought the upper 2MB would still be addressable, if for 
nothing else than for compatibility memory mapped display controllers 
and such.


   Jerry

Re: PDP-11 Memory

[Jerry Weiss via cctalk]

On 1/12/19 11:31 AM, Bill Gunshannon via cctalk wrote:

On 1/12/19 9:20 AM, Bill Gunshannon via cctalk wrote:


Well, the problem is definitely bus grant as with just two memory
cards in the machine I put the disk controller in and it does not
show up in the Map.  The only problem with this is the question
Why?  I  have examined the memory cards.  The C-D (actually, C)
does have the bus grant lines connected.  I even looked under a
magnifier to be sure the trace hadn't been cut and it is intact.
So, what else cold cause this?

(Another question, however, some cards have the ability to open
this.  Why would you ever do that as it would break pretty much
any card that followed?)

Problem fixed.  Note, fixed, not solved.

I dug out another MicroPDP BA23 box.  Stuck the CPU in slot 1.
Started adding the memory cards one at a time and turning the
machine on  waiting for the self-test and then doing a MAP.
Worked perfectly.  The self test got slower as each memory
card was added and the map showed the block of memory and the
assigned CSR.

Congrats on getting this part of the problem resolved.

So, what could go bad on a backplane to cause this problem?
Or, could it be a power supply that is no longer delivering
the rated power?


If you haven't already, check the backplane slots for debris or corrosion on 
the contacts.

Next with a voltmeter check the +5V and +12V first to see if the actual 
voltages are within spec.  If you have an oscilloscope, checking for excess 
voltage ripple.  If the power supplies have are using the original capacitors 
they might not be providing clean power under significant load.

  Jerry

Re: PDP-11 Memory

[Jerry Weiss via cctalk]

On 1/11/19 11:28 AM, Bill Gunshannon via cctalk wrote:

Well, it has been so long since I had to put together an
entire system I forgot what fun it can be.

With almost documentation I was able to configure 4 1meg
memory modules and I tested them all in my 11/23+ box.


KDJ11-B with 4 different (but similar) memory cards.
"MAP" option of the KDJ11 shows 4 meg (minus the I/O
Page) and all the right CSR's for the first four blocks.

Really wanted to make this a deskside so I moved the
cards to a MicroPDP box (Yes, I have a coule of the
deskside pedestals).  Power on, Memory CSR error.
Move then back to the 11/23+ works fine.  If I only
put the first three in the MicroPDP box it works.
But as soon as I try to put in a fourth module I
get the memory CSR error.  Tried different cards
(although working in the 11/23+ box would make me
think it is not a problem with the card) no help.

Anybody care to take a stab at what might be causing
this problem?
1) You might want to check your power supply loading.   You have a lot 
of memory of chips to feed.   The H7864 output at +5V is 36 amps.  
Between the KDJ11-B and 4 memory boards you may be using between 20-25 
amps. Add a  disk controller, disk drive and any other Q-bus devices 
might bring you close to the limits for either +5V or +12V from an aging 
supply.


2) Are the CSR addresses between 17772100-06?  Have you tried to move 
them above this range just to see if the behavior changes?


  Jerry

Re: PDP-11 Memory

[Jerry Weiss via cctalk]

On 1/9/19 12:49 PM, Bill Gunshannon via cctalk wrote:


And then I have two non-DEC module that are unlikely to
have any documentation still floating around for.

Camintonn  CMV-1000  --  As funny as it sounds, this one
   looks  more like a DEC MSV11-QA
   then the DEC ones do, but not exactly.

And one who's maker is only identified by a logo that
looks like 2 interlaced stylized S's.  Model Number
is: 980110014-201 Rev E.

Anybody got any pointers to help me configure some of this stuff?

bill


See http://gunkies.org/wiki/CMV-4000 or 
http://web.frainresearch.org:8080/projects/pdp-11/cam.php

for basic configuration help on the Camintonn Board.

For the M8067-Lx try EK-MSV0P-UG-001_MSV11P_Aug81.pdf.  I believe the 
variants are different memory chip vendors.


980110014 is probably a National Semi NS23S


   Jerry

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

On 1/5/19 11:17 PM, Tony Duell via cctalk wrote:

On Sun, Jan 6, 2019 at 12:45 AM Fritz Mueller via cctalk
 wrote:


   • Try using the drive on the other bus if RSTS can be booted of from DK4.

Easy enough experiment to try; would need to re-jumper the G740 disk selection 
flip chip in the RK11-C too, I guess?

No. One difference between the RK11-C and RK11-D is how it does drive selects.
The RK11-C has 4 select lines on each cable, one is asserted at a
time. The RK11-D
has a 3 bit binary selection. There's a decoder in the RK05 (on the
G740 I think) that
is enabled when the drive is connected to an RK11-D. The RK03 is 1-of-4 select
only which is why it works on an RK11-C and not on an RK11-D.

So on the first drive connector of the RK11-C you get selects 0..3. On
the second
cable you get 4..7. The drive is always jumpered for 0,1,2,3. If it's
jumpered as drive
0 and you connect it to the first connector it's DK0. If it's jumpered
as drive 0 and
you connect it to the second connector it's DK4.

-tony


I have used a Diablo drive with 1 of 4 selection on a third party RKV11 
controller which was 3 bit binary.

It only worked as DK1, DK2 or DK4 for obvious reasons.

Re: uc04 + scsi2sd ?

[Jerry Weiss via cctalk]

Hi Jake,

I don't have a UC04, but its manual states its  Peripheral Interface is 
SCSI single ended.  The pinout is just like the UC07, except for 
terminator power.


    Jerry

On 1/5/19 4:46 PM, Jacob Ritorto via cctalk wrote:

Hey all,
   Anyone know whether the Emulex UC04 works with the sd2scsi?  I just
bought a uc04 and it won't talk to any of my old scsi disks, seems to think
there's supposed to be a "controller" in between :\ yuck.

thx
jake

P.S. While I'm at it, anyone know how to get UC04 to talk to directly to
plain scsi disks and tapes instead of these lunatic ESDI controller bridge
things?

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

On 1/5/19 2:58 PM, Fritz Mueller via cctalk wrote:

On Jan 5, 2019, at 8:07 AM, Noel Chiappa via cctalk  
wrote:


From: Fritz Mueller
All the CPU, FPU, KT11, KW11, and RK11 MAINDECS are passing just fine.

Don't forget Vonada Maxim #12:
  "Diagnostics are highly efficient in finding solved problems.”

Well, there’s wisdom there, for sure! :-)

Last night I also managed to put a new RSTS image, sysgen’d with the 
non-overlapped DK driver, on a different physical pack.  It behaved exactly the 
same way on the real hardware (looping, counting up errors) on boot.

So I think now overlapped vs. non-overlapped DK driver is not the issue, and 
media and image transfer fidelity are not the issue.  A memory or MMU problem 
would be consistent with what has been seen so far, so I may bark up that tree 
a little more today.

Paul, any additional suggestions for things to look at in ODT to try and wring 
out more information on the specifics of the fault?

I did get some MACRO CRC-16 sub-routines coded up last night while waiting for 
various transfers, so I think I’ll go ahead and finish up the standalone CRC 
dumper utility today.

Lastly, a 5V-tolerant USB FIFO breakout board is supposed to show up in the 
mails today.  If that works out as simply as I hope to interface with a DR11-C, 
I should have a much better way to blast bits on and off the machine soon.

 cheers,
   --FritzM.

Along those lines if you have a spare disk pack, try putting RT11(FB,XM) 
on the machine and give it a workout.   This would exercise the machine 
a bit more than MAINDECS, though not as much as RSTS.


A few suggestions from my ancient history running RK11-C and a mix of 
DEC and Diablo Drives.  I regularly disassembled, moved cross country 
and reassembled PDP 11/34 and LSI 11/73 systems. I ran them in small 
rooms which housed saltwater tanks containing sea creatures.


 * Given the age of this equipment, double check all the ground
   connections between the cabinets, PDU's, drives, outlets and CPU.
 * Carefully check for breaks or problems with drive cables and
   terminators.
 * I believe you need a terminator in the RK11-C if the second disk bus
   is unused.
 * Try using the drive on the other bus if RSTS can be booted of from DK4.
 * Make sure you only have one LTC active if a DL11-W and a KW11 are
   both in use.
 * If you are not using a common PDU for the CPU, Drive and RK11-C
   power supplies, make sure they all powered from outlets on the same
   phase.
 * Don't leave the disk packs or drives near the tanks.  The squid have
   good aim and their ink isn't kind to electrical devices.

    Jerry

Re: seagate 801-> Q-bus interface

[Jerry Weiss via cctalk]

On 12/8/18 3:48 PM, Paul Anderson via cctalk wrote:

Does anyone know who made a controller for a Seagate 800 or 801 floppy that
will plug into the Q-bus? Model numbers wound be nice to.

Thanks, Paul


Dilog DQ419
Sigma SDC RXV31


Jerry

Hitachi at 1964 Worlds Fair - Was Re: 1968 Hitachi HIDIC 100 Mini Computer

[Jerry Weiss via cctalk]

On 11/23/18 10:45 AM, Bill Degnan via cctalk wrote:

Sales Brochure scanned
https://www.vintagecomputer.net/browse_thread.cfm?id=587

Bill


One of my earliest computer "game" memories, was at the Hitachi exhibit 
from the 1964 New York Worlds Fair.


I remember a small single capsule that had a CRT display that gave a 
simulation of a rocket launch.  The display showed a single point and 
the axis on either side were labeled, probably altitude and speed.  I 
dimly recall the controls as simple buttons. I've only found a few bits 
of documentation on the web - http://nywf64.com/japan10.shtml where it 
is listed as an Analog Computer and Capcel.    When I went back in 1965, 
the capsule was still there, but non-functional.


If anyone has info or recollections about the exhibit I'd be interested 
and appreciative of in anything you might be willing to share.


Jerry

Re: NeXT Monitor Problem

[Jerry Weiss via cctalk]

On 11/8/18 10:08 AM, Ethan via cctalk wrote:
The monitor works okay; slight burn in, but otherwise looks okay in 
terms
of the phosphor. However, something seems to be wonky with the 
horizontal

scan...the left edge is very wobbly.


Replace all electrolytic caps with new Panasonic of Nichicon 105 
degree caps from a source like Digikey, Mouser, Newark or AVNet.


So... I've heard a lot of NeXT monitors get dim over time. There is a 
tool for rejuvinating CRTs. I wondere if it would work rejuvinating 
NeXT monitor to bring back brightness.


My recollection is that the NeXT monitors left their heater (filament) 
on all the time, when the computer was otherwise off. This causes the 
cathode emission to decay over time.  Some of the rejuvenation devices 
work by simply raising the heater voltage. The others work by 
temporarily raising the heater voltage while using a high voltage 
between cathode and CRT to try to reform the cathodes. I don't have any 
experience in using these with the NeXT monitors, but the first method 
is likely to shorten the filament life even further.  If the CRT is 
"gassy", not much can be done.


I would definitely image the drive before it deteriorates any further.  
Be careful about using the 'dd' command with a 'bs' other than the 
sector size of the disk.  Since the drive already has bad sectors, using 
the "conv=noerror,sync" option has some unexpected side-effects when 
bs>sector size.  See http://www.noah.org/wiki/Dd_-_Destroyer_of_Disks 
under "Copy a drive to an image file"


Jerry

Re: RT-11 DY install

[Jerry Weiss via cctalk]

On 10/17/18 1:53 PM, Don Stalkowski via cctalk wrote:

I'm trying to use a simulated RX02 disk (under simh) with RT-11
and can't seem to get the DY driver to install.

Here's the relevant log:

sim> set ry enabled
sim> att ry0 ry0.dsk
RY: creating new file
RY: buffering file in memory
sim> c


.install dy
?KMON-F-Invalid device installation DL0:DY.SYS

.dir dy.sys

DY.SYS 4P 20-Dec-85
  1 Files, 4 Blocks
  14841 Free blocks

I've tried with 2 different software "kits", the one from the simh site
and the one from bitsavers.

Any ideas?

Thanks, Don



Try
set cpu 256K
set rx disable
set ry enable

show ry
RY    address=1170-1173, vector=264, BR5, 2 units
  RY0    512KB, not attached, write enabled
    double density
  RY1    512KB, not attached, write enabled
    double density

Note: Apparently the RY emulation won't load if more than 256K memory is 
specified as the DEC hardware did not support DMA in a 22bit box.   I'm 
entirely not sure why SIMH has to enforce this as its possible to work 
around (e.g. TSX+ supports buffering the IO). Anyone know how to 
override and load in SIMH?



Jerry

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Jerry Weiss via cctalk]

On 9/21/18 1:06 PM, Fred Cisin via cctalk wrote:

On Fri, 21 Sep 2018, Eric Smith via cctalk wrote:
That's way too good for these 

Re: MicroVAX I

[Jerry Weiss via cctalk]

On 8/14/18 5:40 PM, Josh Dersch via cctalk wrote:

On 8/14/2018 2:12 PM, Ethan Dicks via cctalk wrote:


On Sun, Aug 12, 2018 at 11:36 PM, robertbeauchamp33--- via cctalk
 wrote:
My mother is moving and her spouse has a MicroVax I he bought new 
back in 1984 for some crazy amount. I don’t see this model listed in 
your chart? Can you tell me if there is any value to this machine? 
He also has two original monitors.

There is some value, since it's in a BA23 and _is_ a VAX, even as slow
as can be.  They are somewhat uncommon because they were only
available for a couple of years unlike most other DEC machines.
Having used one in the mid-80s when they were brand new (and $10,000),
they are quite slow and painful and limited to, I think, various
versions of MicroVMS and VMS 4.x, depending on disk size (MicroVMS
fits on a 30MB disk when the full version would not).  I don't recall
if there is any support for them in VMS 5.x - the max RAM is 4MB
(unlike later Qbus VAXen, the RAM is _on_ the Qbus) but one could
easily put a newer disk controller in there other than the RQDX1 and a
larger disk.


Be aware that most (if not all?) QBus SCSI controllers appear to be 
incompatible with the MicroVAX I.  I'm not entirely sure why this is, 
but none of the Emulex, CMD, or Dilog controllers I've tried are 
listed as compatible with the system -- they all state compatibility 
with the II and later .I've tried using them in my MicroVAX I with no 
success.  VMS fails to boot, and Ultrix kernel panics.  Not to hijack 
the thread, but does anyone have any idea why this might be? I'd like 
to get the system doing something interesting and not having to rely 
on very old MFM disks would be nice...


- Josh

No personal experience here, but the Emulex UC04 is listed as MicroVAX I 
compatible. See 
https://ia801902.us.archive.org/11/items/bitsavers_emulex1987_5921218/1987_catalog_text.pdf 
page 27.


The UC07/UC08 is documented not to support the MicroVax I due to lack of 
Scatter/Gather support.  See 
https://ia801902.us.archive.org/11/items/bitsavers_emulex1987_5921218/1987_catalog_text.pdf 
Section 1.6.3  Page 1-22.


Having no Scatter/Gather (aka Qbus IO Map) is not a surprise as the 
MicroVax I only uses Qbus Memory directly.  Thus mapping to a larger 
physical address space should not be needed  (micronote #22). However, I 
don't follow what changed to lose support on the UC07/08.


Jerry

Re: Fairly Extensive Singer/Friden "System Ten" Computer System for Rescue

[Jerry Weiss via cctalk]

On 8/8/18 11:39 PM, Jason T via cctalk wrote:

While I'm not claiming the system, I've let Rick know that I'm close
to it and willing to help facilitate a rescue of at least some of the
lot.

Hi,

I don't have a personal interest in the system, but if you need another 
hand to help with the hauling drop me a line..


Regards,
Jerry

j...@ieee.org

Re: PDP-11/84 Qbus slots for memory

[Jerry Weiss via cctalk]

On 7/22/18 12:54 PM, Noel Chiappa via cctalk wrote:

 > From: Mark Matlock

 > With the 11/83 the position of the memory board ... above the CPU uses
 > PMI

Yes, through the C-D interconnect; described in detail here:

   http://gunkies.org/wiki/CD_interconnect#Use_by_PMI

The 'above' is because the CD interconnect is not a true bus, it only
interconnected pairs of slots.

 > In the 11/84 the CPU is above the MSV11-JE memory

The PMI is still on the CD connector in this machine, but the PMI is wired as
a true bus on the backplane, allowing that ordering.

 > there are 3 Bus slots in the 11/84 above the Unibus map board, would it
 > be possible to put a dual width Q22 I/O board in the second memory slot
 > (not the PMI side of the slot) and have it able to DMA into the
 > MSV11-JE?

It is speculated that this should be possible, but there are jumpers on the
backplane you'd need to pull. See the writeup here:

   http://gunkies.org/wiki/PDP-11/84#QBUS_slots

You might also need a change to the device handler.  For example in 
RT-11 to support the mapped window from 18bit to 22bit, the DU handler 
(for a UC07) uses extended memory subroutine $MPPHY ($MPPTR)  tell the 
controller what addresses to use.  $MPPHY uses Q.PAR, which is the 
relocation constant for the UMR (when present).


Since this I/O isn't going through the KTJ11-B the handler at minimum 
would need to modified to use $MPMEM (Q.MEM) instead, to supply (in 
conjunction with Q.BUFF) the physical address.


Jerry

Re: Another DCJ11 oddity

[Jerry Weiss via cctalk]

On 7/10/18 2:38 PM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > See http://simh.trailing-edge.com/semi/j11.html for information on the
 > design of the J11.

Thanks for that pointer; I don't think I've ever seen that - quite
interesting.

Alas, it didn't have the cache info - but now that I've though about it
overnight, I'm pretty sure the reason for the two bits that do the same thing
is for -11/70 compatability.


There is mention in the J-11 specification documents stating 11/70 and 
11/44 features were the target.  The force miss CCR bits are present 
in both, to allow for segregation of the cache(s).  Thus the 
compatibility may span both.    Interesting to note that if there were 
feature conflicts, these where solved in favor of the 11/44 except for 
special cases.


You can find copies in 
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/j11


Jerry

Re: Another DCJ11 oddity

[Jerry Weiss via cctalk]

On 7/10/18 5:01 AM, Noel Chiappa via cctalk wrote:

So, if one looks up the Cache Control Register in, say, the KDJ11-A
(EK-KDJ1A-UG-002), one sees (in section 1.6.2.1) that there are _three_ ways
to disable the cache: bits 2, 3 ('force miss'), and 9 ('bypass cache').
Looking at the DCJ11 manual (EK-DCJ11-UG-PRE) doesn't provide any additional
insight.

(The 9 bit one is slightly different than the other two, because it causes
cache contents to be invalidated as the code runs, whereas the other two
don't.)

What is going on here, does anyone know? I'm _guessing_ that this is for
compatability with the -11/70, where the cache is divided in two ('two-way set
associative'), and either half can be disabled separately (using the 2 and
3 bits in its CCR).

I suppose only someone who worked on the DCJ11 would know; but I have no idea
how to track down such a person.

 Noel
See http://simh.trailing-edge.com/semi/j11.html for information on the 
design of the J11.  This may give you the 11/70 background you are seeking.


I've always assumed the differences in controls in the CCR as necessary 
to support diagnostics of memory and the cache itself.


In addition to above, there is a bypass cache bit in the PDR (section 
1.5.6.2) for finer control.  This will help support memory mapped 
devices which update those memories independently. Lastly there is a 
selective bypass for certain instructions related to multiprocessing.   
EK-DCJ11-UG-PRE  Section 5.2.4 describes three bypass mechanisms.


   Jerry

Re: Looking for info on Motorola 4015 chip

[Jerry Weiss via cctalk]

> On May 12, 2018, at 1:03 PM, Noel Chiappa via cctalk  
> wrote:
> 
> Hey, all, the RK11-D contoller for the PDP-11 uses Motorola 4015 MSI chips on
> one of the boards (M7254), but I can't find out anything about them. Google
> didn't turn anything up, and the appendix in the RK11-D Maintenance Manual
> that has info about 'all' the MSI chips used in the RK11-D doesn't have this
> one. It appears to be a quad flop - anyone have more info? Thanks!
> 
>   Noel

MC4015 - TTL quad type d latch(flip flop) 

See Section 11 in 
http://bitsavers.trailing-edge.com/components/motorola/_dataBooks/1971_Motorola_TTL_Integrated_Circuits_Data_Book.pdf

Jerry 

Re: PDP11 I/O page memory map

[Jerry Weiss via cctalk]

> On Mar 2, 2018, at 9:11 AM, Paul Koning via cctalk  
> wrote:
> 
> 
>> On Mar 2, 2018, at 8:37 AM, Noel Chiappa via cctalk  
>> wrote:
>> 
>>> From: Jerry Weiss
>> 
>>> Typically execution of the RESET instruction in a user program is
>>> treated as a NOP
>> 
>> Yeah, that's not documented in most PDP-11 CPU manuals, either. It's one of
>> the things that makes the PDP-11 impossible to virtualize; only HALT and SPL
>> trap, IIRC. M[TF]P[ID] doesn't, I think, and neither does WAIT or RT[IT],
>> IIRC.
> 
> RTI/RTT are used in the debugger, so they need to work in user mode.  They 
> refuse to raise your privilege level, though.  But an RTI in user mode that 
> returns to user mode is perfectly ok so it is valid.
> 
> The move from/to previous are also valid, by deliberate design.  This works 
> because the previous mode is explicitly encoded in the PSW, and just like the 
> current mode, cannot be raised by user mode RTI.  It is why the kernel 
> usually sets current == previous == user when constructing the PSW for a 
> process.
> 
> What does the Architecture handbook say about WAIT and RESET in non-kernel 
> modes?  I don't have mine at hand unfortunately.
> 
>   paul
> 
> 

In the Digital Microcomputer Processor Handbook 1979-80 edition page 280 
describes the user mode restrictions on HALT, RESET. and MTPS, but nothing 
about WAIT.   

The PDP11 Handbook 1979  does not  detail user mode implications for MTPS or  
WAIT.  HALT is called out for a trap to 10 in user mode.  Prevention of  a 
"restart" in user mode is mentioned on page 182, but nothing explicit about 
RESET.

As FritzM suggested, it appears there are fewer details in the PDP-11 
Architecture Handbook (1983) for these instructions than these earlier 
references above.HALT trapping to 4 appears for later processors in the 
family differences section, but I did not see much else  for this topic.

Jerry

Re: PDP11 I/O page memory map

[Jerry Weiss via cctalk]

> On Mar 1, 2018, at 8:54 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Charles Dickman
> 
>> So if the I/O page is completely (all processor modes) unmapped is
>> there any way to recover besides a power cycle? Does the RESET
>> instruction disable the MMU?
> 
> Interesting questions!
> 
> The CPU manuals don't say, about the RE$ET; I just tried it on the /23 I
> happen to have next to my desktop, and yes, the RESET instruction does clear
> bit 0 of SSR0.
> 
>   Noel

Typically execution of the RESET instruction in a user program is treated 
as a NOP when the MMU is enabled. 

What generally occurs in most OS'es is that I/O Page is mapped and unmapped 
dynamically
based on which mode is executing.   Interrupts or user program traps cause a 
context switch to kernel mode.  When this occurs page registers with access
to the I/O page defined are activated.  The interrupt or trap is serviced then 
the OS returns 
to running the user mode program.  At this point a switch to back to a set of 
page registers without
I/O mapping occurs.  

There are OS'es that allow regular programs to map the I/O page,  These are 
usually 
special purpose solutions (RT11XM) or granted only to privileged users (RSX11, 
TSX+).

The effect of RESET to initialize the MMR0 (SSR0) register is documented in
the PDP11 Handbook 1979 or the J11 Programmers Reference.  I could not find it 
in the 
reference immediately below, much to my surprise.  

Check out Chapter 1 in the KDJ11-A CPU Module User's Guide for an overview
of  PDP11 memory management. This implementation was (mostly) backward 
compatible with 
PDP-11 models having 22bit , 18bit or  no memory management.
  
Jerry

Re: ADV11-A vs. ADV11-C and 22-bit Bus

[Jerry Weiss via cctalk]

> On Jan 28, 2018, at 12:23 PM, Mark Matlock via cctech  
> wrote:
> 
> Jerry, Noel,
> 
>Thanks for your feedback. Also, Noel was correct on the typos I made on 
> DD1, DE1, and DF1. I was copying from a scanned .pdf and some strange OCR 
> translation was occurring and I missed correcting those.
> 
>Yesterday I stuck the ADV11-A in a MINC-23 with 256 KB memory and verified 
> that it worked. The CSR is different than a MNCAD and the voltage range bits 
> may be different, but when I connected a 40 pin cable and a IDE to screw 
> terminal connector on the I could match up the +4.5 and -4.5 reference 
> voltage signals with the diagram with the screw terminals and then make 
> voltage changes on channel 0 and see the A/D counts change.
> 
>  Today, I cut the BDAL18 BC1 trace to ground, verified it still worked in the 
> MINC, then moved it to a PDP-11/73 RSX11M+ system I use for hardware testing. 
> The RSX system was not configured for this card and the default 400 vector 
> conflicts (I think) with the bottom of kernel stack so I’ll need to either 
> move the vector switches on the card down or re-sysgen this test RSX system. 
> Thus, the only quick testing I could do is via the CSR. 
> 
>   Also, to make it easy to see values change I used the 2 digit LED display 
> next to the console port to display the least significant bits of the 
> readings. This is a technique I use to debug interrupt routines as you can 
> write a 2 digit octal number with a simple MOV.
> 
>I didn’t loop on the status bit because RSX is multiuser/tasking, but just 
> used a 1 second mark time to assure the conversion was done. This would be 
> changed to an interrupt service routine once I fix the vector issue. Using 
> the LED display made the test code very simple:
> 
>….
> 
>  So Noel and Jerry, you are correct it is that simple. If the A/D was DMA, 
> that would be another situation (like the RX02 controller).
> 
> Best Regards,
> Mark 


Glad to hear that the surgery was a success.   Just shows that if you do 
research and are careful you can make good use of these cards.

The DMA Qbus cards that only use 16 bit or 18 bit addressing can still be used 
in a 22bit OS in most cases.  
For example in RT11/TSX+ there are DY handlers utilize a low memory buffer that 
allows their use.Just a tad bit slower with an 11/73 if the IO request is 
over the 18 bit boundary.

Jerry 
j...@ieee.org

Re: ADV11-A vs. ADV11-C and 22-bit Bus

[Jerry Weiss via cctalk]

> On Jan 27, 2018, at 11:16 AM, Mark Matlock via cctech  
> wrote:
> 
>   I have an ADV11-A that I would like to use in a Q22 RSX11M+ system. The 
> ADV11-C will work in a 22-bit Bus system from what I understand but the 
> ADV11-A was made for 18 bit Bus systems. In the OEM Micronote book, Note 5, 
> it states:
> 
>Any device which uses backplane pins BC1, BD1, BEl, BF1 or DC1, 001, DEl, 
> OF!, for purposes other than BDAL18-21 is electrically incompatible with the 
> 22-bit bus and may not be used without modification. 
> 
> 
>   Further down it lists the ADV11-A as a device that does not meet the 
> requirements for a Qbus 22-bit system because:
>ADV11 (A012).   A/D Converter. (Use of BC1 for purposes other than 
> BDAL18)
> 
>   When I look at the Board connector B pin C side 1 (component side) the BC1 
> pin is tied to ground. Several other pins are also tied to ground on that 
> connector such as BC2, BJ1, and BT1. Other than BC1 which is BDAL18 being 
> tied to ground the pins BDAL19 (BD1), BDAL20 (BE1), And BDAL21 (BF1) are all 
> not connected to anything. This also matches the field engineering print for 
> ADV11-A (B-TC-ADBV11-A-1) where BC1 is shown tied to ground on page 21.
> 
>   So it looks like if I simply cut the trace between the BC1 finger and its 
> connection to ground on the board it would become Q22 compatible.
> 
> Is it that simple?
> 

I am considering the same modification to my own ADV11-A.  I just located the 
field maintenance print you referenced, so I can now research this a bit 
further myself.

Being a interrupt only device and using on BBS7 to decode the IO page, this 
should function in an Q/Q backplane slot "in theory".   


Jerry
j...@ieee.org

Re: ID board Dilog SU723A

[Jerry Weiss via cctalk]

> On Jan 8, 2018, at 7:17 PM, John Welch via cctech  
> wrote:
> 
> Thanks!  I did some searching but all The Google could find were a few 
> re-sellers that had the board but no info.  The 'feet' of the board (the part 
> that plugs into the buss sockets) are labeled C, D, E, and F so it sort of 
> smelled like unibus.
> 
> Have you ever used one of these boards?
> 
> 
> On 1/8/2018 9:18 AM, Phil Blundell wrote:
>> On Mon, 2018-01-08 at 09:13 -0600, John Welch via cctech wrote:
>>> Does anyone know this board?  I think it may be a SCSI controller. I
>>> cannot tell if it is Unibus or Qbus.
>> 
>> According to:
>> 
>> http://www.dilog.com/unibus.html
>> 
>> it's:
>> SU723A   SCSI, TMSCP, 7drives, Quad Height.
>> 
>> and (judging from the URL) it's presumably Unibus.
>> 
>> hth
>> 
>> p.




Take a look at  
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dilog/2120-0147_DU686_ESDI_MSCP_Nov87.pdf
 

   

Its only Unibus type device I have seen a Dilog Manual for. It might help you 
sort out the Unibus addressing 
if the basic design of the host controllers are consistent between products. 
Obviously the media side will
be completely different.


Jerry

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

> On Dec 16, 2017, at 7:59 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 12/16/2017 05:21 PM, Fred Cisin via cctalk wrote:
> 
>> So, some of us do not trust the labels on disks.
> 

I don’t trust the labels on my floppies.  

Especially those with with my handwriting.

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

 Glad to hear that you cleared that up.   

For the other floppies.

1)  DUMP/TERM/RAD50/END:0 DY1: 
 If you share the listing that will give us some hints as to the OS on the 
floppies.

2) DIR/BAD DY1:
will do a bad block scan to see if can read all of the blocks on the media. 
 It
does not require an RT11 directory, despite the command name.  It uses
the utility DUP.SAV with the K option, not DIR.SAV  You will hear the floppy
reset if it sees a bad spot as it attempts a retry.  The number of retries
is configurable via a SET command.

For files with an RT11 Directory, DIR/BAD/FILES will include the file name
of files affected by unreadable blocks.

You can do the same with the RL02 Drives.

Jerry

> On Dec 16, 2017, at 2:28 PM, Aaron Jackson via cctalk  
> wrote:
> 
> I just checked all of them in RT-11, out of 12 floppies, two of them
> were bad, or at least I am unable to perform dir in RT-11.
> 
> My source of confusion comes from both A) not being able to boot from
> any of them, and B) not being able to dump them using vtserver. The ones
> labelled RT-11 don't actually have RT-11 on them, just some random
> files, and these were the ones I had tried to boot from.
> 
> I'm not sure why vtserver doesn't seem to work though. I have Kermit in
> RT-11, is there a way to dump the other drive over this? I would like to
> put LSI Unix on one of the floppies, can this be done with Kermit too?
> 
> While on the topic of vtserver, it also doesn't seem to like my RL02
> drive. If I try to write to it or dump a cartridge, it tells me that it
> was unable to read the labelsector. About the thing vtserver has done is
> launch itself over odt.
> 
> RT-11 is unable to list the files on the RL02 drive, but maybe they are
> UNIX or maybe they are dead packs...
> 
> Thanks,
> Aaron.
> 
> 
> systems_glitch via cctalk writes:
> 
>> We've gotten around the formatting issue by formatting SSSD using ImageDisk
>> on a regular PC (with a floppy controller that supports single density/FM,
>> of course). If you want RX02 media there's an XXDP routine to upconvert
>> RX01s to RX02s.
>> 
>> Thanks,
>> Jonathan
>> 
>> On Sat, Dec 16, 2017 at 2:02 PM, Chuck Guzis via cctalk <
>> cctalk@classiccmp.org> wrote:
>> 
>>> On 12/16/2017 10:43 AM, Fred Cisin via cctalk wrote:
 On Sat, 16 Dec 2017, Aaron Jackson via cctalk wrote:
> Well, would you believe it. It was the disks after all. I can't believe
> they are all bad!
 
 I can believe it.
 Were they "bad"?
 Or just not what they were labelled as being?
>>> 
>>> I suspect that they weren't formatted to the 3740 spec (26/128 FM).
>>> ISTR that the RX02 doesn't have formatting abilities.
>>> 
>>> The other possibility is that the disks were DS rather than SS
>>> (different index aperture position).
>>> 
>>> --Chuck
>>> 
>>> 
>>> 
> 
> 
> --
> Aaron Jackson
> PhD Student, Computer Vision Laboratory, Uni of Nottingham
> http://aaronsplace.co.uk

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

> On Dec 9, 2017, at 1:25 PM, Aaron Jackson  wrote:
> 
> Thanks Jerry. That was very helpful. Found a stray piece of metal lying
> across the board next to an AND gate, which is slightly
> disconcerting. Possibly a stray wire clipping. Both drives pass the
> diagnostics.
> 
> It's strange though, if I try to dump using vtserver using a floppy
> which passed the diagnostics, it fails. So, not sure. Will have to
> investigate a bit more.
> 
> Thanks again,
> Aaron.

Glad it all worked out.   I can’t advise on the VTServer issue as 
I have not used it.  Perhaps others can advise further.

Have fun!

Jerry

Re: Re; Revive 11/34

[Jerry Weiss via cctalk]

> On Dec 9, 2017, at 8:23 AM, Noel Chiappa via cctalk  
> wrote:
> 
> 
>> From: Jerry Weiss
> 
> And the same for Jerry...
> 
>> It won't seat evenly if reversed. At least that is what my scraped
>> knuckles remember. 
> 
> Nope, they go in quite fine the wrong way around; I just checked.
> 
> Make sure they are in the right connector (D) and the right way around; I
> haven't checked to see if damage is likely to result on an error - does
> anyone know offhand?

Yup, they insert reversed.

I remember the limited keying resulted in a offset that you could sense if
you had any feeling left in those fingers.  If both edges aren’t flush
with the connector, its backwards.

Re: Revive 11/34

[Jerry Weiss via cctalk]

> On 12/8/2017 3:50 PM, Jerry Weiss wrote:
>> On Dec 8, 2017, at 2:25 PM, John Welch via cctech 
>>  wrote:
>> 
>>> I am reviving an 11/34. Cards are:
>>> 
>>> Back/Fans [M8266]  Front of machine where keypad is.
>>>   [M8265]
>>>   [M9312] [M7859]
>>>   [M7762]
>>>   [OPEN]  [M7860]
>>>   [M7840]
>>>   Bus grant in third from front slot
>>>   [M9302] [M7856]
>>> The 7856 is hooked to a cable/null modem (i think)/PC running 
>>> XP
>>> 
>>> When I first powered on the programmers console said '7' and I powered off, 
>>> then back on, and now it says '5'
>>> 
>>> Any suggestions as to what to try first?  I may have the bus grant in 
>>> backwards.  I have other boards I can try.
>>> 
>>> Sincerely,
>>> John Welch
>>> :qw
>>> 
>> 
>> 1) The G727A bus grant card is keyed (somewhat). It should be in Row D 
>> (fourth from the back)
>>  It won’t seat evenly if reversed. At least that is what my scraped 
>> knuckles remember. 
>> 
>>  You can temporarily pull it out to finish the check out.  There’s 
>> nothing past the 
>>   M7840 that requires DMA.

Ignore this last suggestion (see below).

>> 
>> 2) Check the baud rate, stop bits and parity settings on both the 
>> Hyperterminal and the M785 to make sure they match. 
>>  
>> 3)  Are you seeing a single 7 or 5 on  KY11-LB Programmer Console or on the 
>> Hyperterminal?
>>  
>>  An other status led’s lit on the KY11-LB?
>> 
>> 4) I don’t see any memory listed…  Do you have any M7847’s?  
>> 
>> 5) Grab a copy of EK-11034-UG-001 PDP-11-34 System User’s Manual for more 
>> info.
>> 
>> 
>> Jerry
>> 
>> 
> 
> 
> On Dec 8, 2017, at 5:26 PM, John Welch via cctech  
> wrote:
> 
> Update:
> This is the map of the machine:
> 
>    AAA BBB CCC DDD EEE FFF 
> (Rear/Fans/Power Supply) 1 [M8266] (Front/Keypad/DC ON)
>  2 [M8265] 
>  3 [M9312] [M7859] 
>  4 [M7891] 
>  5 [M7762] 
>  6 [M7860] 
>  7 [M7840] 
>  8 GNT 
>  9 [M9302] [M7856] 
>    AAA BBB CCC DDD EEE FFF 
> Reseating the ribbon cable on the M7859 changed the display.  I have replaced 
> the M7840 with a G7273.
> Now when I power on it says (dim)0, (bright)0, blank, (dim)0, blank, blank.
> I have reseated the M7859, I don't think I have another one.
> Maybe I should hit it with a vacuum.
> I had forgotten about needing to cut a wire for DMA.  Can you give me a 
> refresher on how to tell which slots are cut?  I remember having to turn the 
> chassis over and looking for a particular wire but that was >15 years ago.

Your update has a M7891 (MS11) which addresses the memory questions.

The Programmers Console display is not correct.  It should be 7 digits, either 
000 when running or some other data or address value.
Check the cable orientation.  see 
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/1134/KY11-LB_MaintMan.pdf
 

 chapter 9.

A light cleaning and reseating all the boards is an easy place to start.

For NPG changes see 
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/1134/1134_UsersManual.pdf
 

 section 4.2.2.2

Ignore my earlier comment about leaving out the G727a.  I had slipped into QBUS 
thinking mode in error.



> On Dec 8, 2017, at 5:49 PM, John Welch  wrote:
> 
> I also have an 11/04 that I went and drug out.  It is configured like this:
> 
> 11/04:
>    AAA BBB CCC DDD EEE FFF  
> (Rear/Fans/Power Supply) 1 [M7263]  (Front/Keypad/DC ON)
>  2 [M7847]  
>  3 [M7859]  
>  4 [M7847]  
>  5 GNT  
>  6 [M7762]  
>  7 [M7840]  
>  8 [DILOG]  
>  9   {nothing}  
>    AAA BBB CCC DDD EEE FFF  
> I am 

Re: Revive 11/34

[Jerry Weiss via cctalk]

On Dec 8, 2017, at 2:25 PM, John Welch via cctech  wrote:
> 
> I am reviving an 11/34. Cards are:
> 
> Back/Fans [M8266]  Front of machine where keypad is.
> 
>   [M8265]
> 
>   [M9312] [M7859]
> 
>   [M7762]
> 
>   [OPEN]  [M7860]
> 
>   [M7840]
> 
>   Bus grant in third from front slot
> 
>   [M9302] [M7856]
> The 7856 is hooked to a cable/null modem (i think)/PC running XP
> 
> When I first powered on the programmers console said '7' and I powered off, 
> then back on, and now it says '5'
> 
> Any suggestions as to what to try first?  I may have the bus grant in 
> backwards.  I have other boards I can try.
> 
> Sincerely,
> John Welch
> :qw


1) The G727A bus grant card is keyed (somewhat). It should be in Row D 
(fourth from the back)
 It won’t seat evenly if reversed. At least that is what my scraped 
knuckles remember. 

 You can temporarily pull it out to finish the check out.  There’s nothing 
past the 
  M7840 that requires DMA.

2) Check the baud rate, stop bits and parity settings on both the Hyperterminal 
and the M785 to make sure they match. 
 
3)  Are you seeing a single 7 or 5 on  KY11-LB Programmer Console or on the 
Hyperterminal?
 
 An other status led’s lit on the KY11-LB?

4) I don’t see any memory listed…  Do you have any M7847’s?  

5) Grab a copy of EK-11034-UG-001 PDP-11-34 System User’s Manual for more info.


Jerry

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

On Dec 8, 2017, at 5:17 PM, Aaron Jackson  wrote:
> 
>>> On Dec 8, 2017, at 12:53 PM, Aaron Jackson via cctalk 
>>>  wrote:
>>> 
 On Fri, Dec 8, 2017 at 3:03 PM, Aaron Jackson  
 wrote:
> 
> Manual says it should be S1=off, S2=on for RX211 and RXV21
 
 In the photo, I think S1 is on and S2 is off. Check them with an
 ohmmeter if in doubt!
 
 -tony
>>> 
>>> Yes - you are right. I switched them back to how they were when I got
>>> the drive. I think one of the switches was half down because XXDP
>>> actually does something now.
>>> 
>>> Most of the tests now look something like this:
>>> 
>>> CZRXFB0 DVC FTL ERR  00034 ON UNIT 00 TST 031 SUB 000 PC: 003476
>>> SECTOR ADR - LGC TST
>>> SECTOR ADDRESS ERROR
>>>  EXPECTED SECTOR=18.
>>>TARGET SECTOR=17.
>>> 
>>> I suppose these should match?
>>> 
>>> Starting to think I might need to confuse myself with my logic analyzer
>>> and the RX02 control board.
>>> 
>>> Thanks,
>>> Aaron.
>> 
>> To isolate the problem further, try to see if any of the errors follow
>> the media  as you move them between drives.  
>> 
>> If the same errors occur on both drives, regardless of media then the
>> RX02 system board or perhaps the Qbus controller are at fault.  
>> The field maintenance prints should allow you to trace the fault down
>> a bit further,  with or w/o a logic analyzer.
>> 
>> How many different types of errors do you see?
>> 
>> Jerry
> 
> Thanks for the info Jerry.
> 
> I get read errors, data errors, density errors, sector addressing
> errors. Probably every kind of error xxdp can give :)
> 
> Please see this link if you are interested:
> 
> https://aaronsplace.co.uk/private/o/48859c14f6a619a5316d6af37d60579c.txt
> 
> I will take a proper look through the field manuals tomorrow, and also
> try what you suggested with trying the same media in both drives.
> 
> Thanks,
> Aaron.


 When you have many errors it can be hard to separate the primary fault(s) from 
the knock-on errors.
 The M7745/M7744 or Media Errors dominate the entries.
 
1) Try to verify the media is a DEC 8 Inch formatted RX02 or RX01 if you do not 
know the source of the 
 the disks.   The disk should have only 1 hole punched for index  on the 
media itself.   Even if it is
 a DEC Brand, there’s still possibility that the media has been exposed to 
strong magnetic fields.

 I have not seen much natural  bit-rot on my floppy media, but YMMV.   If 
could find someone local 
 with RX02 drives to confirm your media, that would also help rule out some 
things.   

  Many third party drives and controllers that were DEC compatible also had 
the ability to do a 
  low level format of media, something the native RX02 did not.  So if the 
media type is correct, but
  the format is not, they may be salvageable (with complete loss of 
original data).

2) Check the connections between the drives and controllers. Gently clean 
contacts, especially anything
gold plated.  Getting clean signals from the floppies is critical if the RW 
electronics are to function.

3) Try and contrast to the other drive as previously covered.  

This will help rule out a few things and provide some better direction.


Jerry 

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

> On Dec 8, 2017, at 12:53 PM, Aaron Jackson via cctalk  
> wrote:
> 
>> On Fri, Dec 8, 2017 at 3:03 PM, Aaron Jackson  
>> wrote:
>>> 
>>> Manual says it should be S1=off, S2=on for RX211 and RXV21
>> 
>> In the photo, I think S1 is on and S2 is off. Check them with an
>> ohmmeter if in doubt!
>> 
>> -tony
> 
> Yes - you are right. I switched them back to how they were when I got
> the drive. I think one of the switches was half down because XXDP
> actually does something now.
> 
> Most of the tests now look something like this:
> 
> CZRXFB0 DVC FTL ERR  00034 ON UNIT 00 TST 031 SUB 000 PC: 003476
> SECTOR ADR - LGC TST
>  SECTOR ADDRESS ERROR
>   EXPECTED SECTOR=18.
> TARGET SECTOR=17.
> 
> I suppose these should match?
> 
> Starting to think I might need to confuse myself with my logic analyzer
> and the RX02 control board.
> 
> Thanks,
> Aaron.

To isolate the problem further, try to see if any of the errors follow
the media  as you move them between drives.  

If the same errors occur on both drives, regardless of media then the
RX02 system board or perhaps the Qbus controller are at fault.  
The field maintenance prints should allow you to trace the fault down
a bit further,  with or w/o a logic analyzer.

How many different types of errors do you see?

Jerry

Re: VAX Q-bus identical to PDP-11 Q-bus?

[Jerry Weiss via cctalk]

> On Dec 7, 2017, at 1:22 PM, allison via cctalk  wrote:
> …..
> 
> As such PDP11 and VAX support is there unless the OS in non-DEC in
> origin and even then if the
> time frame made it a marketing requirement the third party OS vendor had it.
> 
> An example is a RD54 on a Qbus PDP-11 running RT11.  You need the LD
> driver to partition the
> disk as RT supports only 32mb or smaller devices and the RD54 is 150.  
> It was supported but
> not ever sold that way.
> 
> Things like block replacement are options of the OS and the device IO is
> then just a
> interface.  The protocol for to talk to the device is a lower level
> layer in most cases.
> 


I think you are actually referring to the logical partitioning in the DU 
handler under
RT-11.  The DU (MSCP) handler managed this and had the ability to allow
the disk to handle bad block replacement (RA type device) or do it in the 
controller (RD).

The KZQSA is not listed as supported in V5.6.   i have not seen documentation
on how it configured SCSI drive support.  I would be interested to know if 
anyone tried
to use it under RT-11.


Jerry 

Re: VAX Q-bus identical to PDP-11 Q-bus?

[Jerry Weiss via cctalk]

The metal face on the Q-Bus cards was there as part of the solution to meet FCC 
(or equivalent) regulations to
 reduce electrical interference to radio receivers and other devices.

If you can physically fit it into a older Qbus backplane and sort out the 
cabling it should work
provided you have the necessary drivers.  

However, I’m not aware of drivers for the M5976 for most PDP/LSI-11 operating 
systems.  Even for VMS or Ultrix
the card is reported to only support specific DEC hardware, even thought is 
SCSI controller.  

Jerry


> On Dec 5, 2017, at 9:16 AM, Aaron Jackson via cctech  
> wrote:
> 
> I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
> (M5976). If the card did not have the large metal face, would it work in
> a Q-bus PDP-11? We are not going to potentially ruin a card by trying
> this, but I am interested to know if this is the case.
> 
> Thanks,
> 
> Aaron.
> 

Re: RL02 Spinup fails

[Jerry Weiss via cctalk]

> On Nov 11, 2017, at 2:42 PM, Aaron Jackson  wrote:
> 
>> Aaron,
>> 
>> Do not underestimate the need for termination, even with a very short 
>> external cable.
>> When you factor in the internal cables runs,  crosstalk or signal 
>> reflections which interfere
>> with operation may still be present, especially when data transfers start.
>> 
>> If you have access to another bootable drive (8inch floppy?), suggest you 
>> load the
>> XXDP+ diagnostics for RL Drives.
>> 
>> Jerry
> 
> Hi Jerry, thanks for the information.
> 
> I had built several terminators, but being terrible at geometry I always
> did something wrong. I have now fixed one of the terminators I built. I
> had pins 1 and 40 mixed up, the rest of the terminator is basically a
> mirror copy.
> 
> Unfortunately I still have the same error.
> 
> I have an RX02 drive but no controller yet, so I'll have to continue
> investigating in the dark.
> 
> Thanks,
> Aaron.

I too have had home built cables cause me grief because
of confusions around pins, keying or just being cable to properly fasten the
connectors. 



Could elaborate a bit on this part of your earlier message.

> I managed to boot into XXDP today using tu58em and ran the RLV12
> controller test. It seems though that the version of XXDP I loaded does
> not support the 22bit address (17774400) and defaults to the 16bit
> address (174400) so it just shows errors for everything.

VRLBCO expects 16 bit addresses for hardware setup.  Most of the 
XXDP diagnostic programs understand the 16 bit address for IO page
type devices.   

Separately, if this diagnostic itself is not able to use 22 bit memory 
on an 11/73 with 1MB ram, then you may have other issues.  It 
should not be tossing errors.  The fact that XXDP cannot boot
into extended addressing (XXDPXM) is not a good sign either.

Jerry

Re: RL02 Spinup fails

[Jerry Weiss via cctalk]

> On Nov 11, 2017, at 10:58 AM, Aaron Jackson via cctalk 
>  wrote:
> 
> ……...
> The RL02 technical manual says to figure out why a drive error occurred,
> I can execute a get status command (?) and then perform an MPR read
> (?). So while I don't know how to do that, the error could be one of the
> following (apparently)
> 
> - spin error. I assume it's not this because the ready light is on?
> - seek time out. Maybe this?
> - write lock. Only set when the drive is write protected.
> - current head error. Set when write current is detected while reading.
> - write data error. Set when no transitions are detected during writing.
> 
> So, pretty confused.
> 
> Thanks,
> 
> Aaron.
> ,
>> 
>>> Well, some progress.
>>> 
>>> It seems that a terminator is not required so long as the cable is VERY
>>> short. The controller RLV12 controller appears to have a few termination
>>> resistors on it anyway. There is no fault light appearing and the drives
>>> spin up fine. Mine cable is less than 20cm and the PDP is sitting just
>>> on top of the drive.
>>> 
>>> I can see that the drive is communicating because the lsb of the csr
>>> changes flips between 0 and 1 when I load and unload the drive.
>>> 
>>> I wanted to try and dump the disks using vtserver, but when I run the
>>> copy program I end up with the following
>>> 
>>> ]] Enter name of input record/device: rl(0,0,0)
>>> ]]
>>> ]] Can't get rl(0,0,0) sts
>>> ]] rl(0,0,0) err cy=0, hd=0, sc=2, rlcs=142205, rlmp=0
>>> ]] rl(0,0,0) error reading labelsector
>>> ]] Enter name of input record/device:
>>> 
>>> The same happened on both packs - they have both been cleaned and look
>>> as though they are in good condition. The heads have been cleaned too.
>>> 
>>> Given that the drive appears to be communicating with the PDP-11, where
>>> might this problem come from?
>>> 
>>> Thanks,
>>> 
>>> Aaron.
>>> 


Aaron,

Do not underestimate the need for termination, even with a very short external 
cable.
When you factor in the internal cables runs,  crosstalk or signal reflections 
which interfere 
with operation may still be present, especially when data transfers start.

If you have access to another bootable drive (8inch floppy?), suggest you load 
the
XXDP+ diagnostics for RL Drives.  

Jerry

Re: Diablo 31 air filters / plugs ?

[Jerry Weiss via cctalk]

> On Oct 7, 2017, at 5:00 PM, Al Kossow via cctalk <cctalk@classiccmp.org> 
> wrote:
> 
> On 10/7/17 1:31 PM, Jerry Weiss via cctalk wrote:
> 
>> There wasn’t a head lock.
> yes, there is.
> 
> It is a 'L' shaped bracket that screws onto the top of the actuator.
> Details in the manual
> 
> You can tie-wrap the actuator or tape the disk with the cylinder numbers
> on it to keep it from moving without it, though
> the heads won't come together without tripping the pawl for the dash pot
> which is extremely unlikely to happen
> 


Sorry - I did a quick check of few manuals and parts breakdowns to see if
my memory was correct prior to posting, but I missed It.   
Ours were hand-me-downs and we probably didn’t get this bit on ours.

These were nice units, and unlike the DEC RK05 series
you didn’t have any nicads, belts or positioner light bulbs to go bad.

Jerry 

Re: Diablo 31 air filters / plugs ?

[Jerry Weiss via cctalk]

> On Oct 7, 2017, at 12:55 PM, jos via cctalk  wrote:
> 
> 
> Looks like another computer will be joining the stable shortly, containing a 
> Diablo 31 drive.
> 
> From the manual it looks that it does not need heads to be locked down for 
> transport, so I should be save there.
> 
> But since i will need to fabricate cables : are connector plugs still 
> obtainable ?
> And what are people using for air filters these days ?
> 
> 
> 
> Jos
> 


There wasn’t a head lock. The head loading mechanism are designed to retract 
them from the surface when the power is removed.

I shipped these cross country many times (back in the day), and out of an 
abundance of caution I recall manually securing the head positioner so it 
didn’t move in and out.  


Jerry 

Re: The origin of SCSI [WAS:RE: The origin of the phrases ATA and IDE ]

[Jerry Weiss via cctalk]

The DK Driver for VMS versions around 5.x definitely had a problem with non-DEC 
disks.  6.X and greater were slightly more forgiving.

The specifics are summarized in a note from Ralph Weber in 
https://groups.google.com/forum/#!search/SCSI$20Mode$20Page$20Requirements$20$20axp/comp.os.vms/RAaUpP_XXEw/BWn64YZYwBQJ
 .  

I don’t think there is list of non-DEC disks in the driver as it instead 
checked the SCSI Mode bits and other disk configuration settings.   There is a 
list (table) for DEC Drives (idiosyncrasies?) and another SCSI2 Tagged Queuing 
devices requirements used for Clusters in the driver.

Regards,
Jerry



> On Oct 5, 2017, at 6:23 PM, Peter Coghlan via cctalk  
> wrote:
> 
> 
> 
>> 
>> The biggest problem you had was the requirement to assert ATN when selected 
>> properly.� Later the tag queuing caused huge headaches as manufacturers 
>> implemented that feature.
>> 
>> It eventually was made mandatory for the most part by linux, and perhaps 
>> Windows requiring the tag queuing drilled own to the lowest level of the 
>> system's use of the disk.  The capability to do that, or fake it is required 
>> to allow the kernel to queue commands to run, and have the OS continue to 
>> run till command completion.
>> 
> 
> I recall VMS having issues with SCSI disks which claimed to do tag queueing
> (and bad block replacement) but didn't do it right, before I'd even heard
> of linux.
> 
> Customers complained that VMS refused to work with commodity SCSI disks
> and thought that it was a conspiracy to get them to buy expensive DEC branded
> disks.  DEC claimed that only the disks with their firmware did tag queueing
> and bad block replacement correctly.  The VMS SCSI driver supposedly had 
> (has?)
> a list of specific disks known to mess up which it would refuse to bring
> online.
> 
> I wasn't well up on Sun but I expect the same issue existed there too.
> 
> Regards,
> Peter Coghlan.

Re: Strange grounding problem

[Jerry Weiss via cctalk]

> On Sep 27, 2017, at 8:14 PM, Charles Dickman via cctalk 
>  wrote:
> 
> On Wed, Sep 27, 2017 at 8:23 PM, Adrian Graham via cctalk
>  wrote:
> 
>> Schematic for the circuits is here - 
>> http://www.binarydinosaurs.co.uk/newbrainPowerupCircuits.png 
>>  - top circuit 
>> is PWRUP and the bottom one is RESET that goes straight to the Z80.
>> 
> 
> CD4000 logic can't handle inputs pulled above the power pin or below
> the ground pin without the possibility of malfunctioning or even
> complete failure. Google for "CD4000 parasitic SCR" or "CMOS
> latch-up". When power is cycled rapidly, the caps will still have
> charge which could cause the latch-up. I did some industrial control
> designs with CD4000 and used similar timing circuits, but always
> included diodes to prevent inputs from being driven too high or too
> low. I would have put diodes across both of the resistors.
> 
> Adding your probes may change the currents inside the chip that change
> the latch-up behavior. Of course it also only makes sense if the power
> is cycled quickly for some value of quickly. Others may have an
> explanation, but that was my first thought from looking at the
> schematic.
> 
> -chuck

The capacitors may have become leaky, and start to as resistors in the 100K 
ohms range.

If so, the circuit now contains a voltage divider and and not meet the 
threshold needed for 
the logic gate to switch.  The probes have their own resistive component and 
thus
shift the other side of the divider, which puts the signal back into a 
functional range for
the Schmitt Trigger.

Jerry

Re: M8195 SLU died while in use

[Jerry Weiss via cctalk]

> On Sep 25, 2017, at 8:37 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Aaron Jackson
> 
>> a PDP-11/73, M8192 CPU, two M8067 RAM, M7195 ... While playing in ODT,
>> the console completely stopped responding.
>> ...
>> The CPU shows 1000, which I believe is fine, and means it's in ODT. The
>> SLU card has . I've had a Google and I believe this means it can't
>> communicate with the CPU.
>> ...
>> Does anyone have any ideas? It was working and then it wasn't :(
> 
> 
> I'm not familiar with the MXV11-B (M7195), and I couldn't turn up a manual
> online, but likely those LEDs are set by software (I can't imagine how one
> would turn on a "can't communicate with the CPU" bit in hardware ... unless
> it's a flop that's set on power-on, and cleared by the first bus cycle to the
> card)...
> 
> 

There is a user guide at http://vaxhaven.com/images/6/6d/EK-MXV1B-UG-001.pdf
The LED’s are controlled by a single write only register as Noel suggests.  
You might try to blindly set or clear the leds with a poke to 7524.
1 to turn the LED OFF, 0 to turn ON. By blind, I mean don’t expect any echo from
ODT. 

//

I had a M8192 go bad while I was using  it a few months ago.  One minute fine 
and 
then the next it would crash an OS sporadically crash, then failed to boot.  

ODT was still active, but after using it to look at a few registers or memory
locations it would just start streaming garbage to the console until power 
reset.  
Confirmed it was only this card.   I swapped out the DCJ-11 with no effect, so 
its definitely
the board itself.  Other than trying to vary the +5 supply to the backplane 
within normal margins
to see if it would recover, I haven’t had a chance to work on it more.  I’d 
definitely
like to understand what form of bit or component rot is going on here when I 
get 
more time with it.

Jerry 

Re: QDSS qbus VCB02 8-plane video

[Jerry Weiss via cctalk]

> On Sep 3, 2017, at 7:56 PM, Charles Dickman via cctalk 
>  wrote:
> 
> I found that I have a board set for a VCB02. My research says it will
> work in either Q CD or Q Q slots of a qbus backplane. True?
> 
> I have no cabinet kit. Is it documented anywhere? The closest I could
> find are some hand written notes in the VCB02_PrelimHwRef.pdf on
> bitsavers.
> 
> Chuck


Search for AZ-GLGAB-MN_VCB02_Technical_Manual_Feb86.pdf.  It has the
backplane requirements.

The IO connections for video are found here - 
http://antinode.info/dec/vcb02_cables.html

Regards,
Jerry,  WB9MRI
j...@ieee.org

Re: RX02 Emulator

[Jerry Weiss via cctalk]

> On Sep 1, 2017, at 10:41 AM, Douglas Taylor via cctech 
>  wrote:
> 
> In my other post I asked about DEC 11/2 and 11/03 cpus and 18/22 bit 
> backplanes.  I am still interested in this but I am considering what type of 
> disk to run from.
> 
> I ran into a rx02_emulator on github and looks quite interesting, since it 
> uses an actual DEC RXV21 interface it would be compatible with the 18 bit 
> addressing.
> 
> Does anyone have experience with this emulator?
> 
> Where can you get the circuit board that is part of this project?
> 


See 
http://www.vcfed.org/forum/entry.php?667-RX01-RX02-Drive-Emulator-using-Arduino-and-a-custom-shield
 

 

Re: DEC ll/03 in 22 bit backplane

[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

[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

[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

[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: Champaign, IL to Iowa City, Iowa and back trip

[Jerry Weiss via cctalk]

> On Aug 19, 2017, at 11:08 AM, Jon Elson via cctalk  
> wrote:
> 
> On 08/19/2017 10:03 AM, Tony Aiuto via cctalk wrote:
>> A well priced PDP8 just went on sale in Iowa. I can't get it back from
>> Champaign to NYC, but someone else might be able to snatch it.
>> http://www.ebay.com/itm/Digital-Equipment-Corporation-DEC-PDP-lab8-e-Vintage-1970s-computer/15297190?_trkparms=aid%3D888007%26algo%3DDISC.MBE%26ao%3D1%26asc%3D41376%26meid%3D9253420ebdf64d829d68079589c3d04a%26pid%3D19%26rk%3D1%26rkt%3D1%26sd%3D152665094101&_trksid=p2047675.c19.m1982
>> 
>> 
> That must be a LAB-8, seriously cool!  Currently $676, but I suspect will go 
> higher.
> 
> Jon


I won’t dream about this seriously until the last day.   I treat these just 
like the NBA playoffs rounds. 


Jerry
j...@ieee.org

Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 15, 2017, at 2:33 PM, Don North <no...@alum.mit.edu> wrote:
> 
> On 8/15/2017 2:10 AM, Jerry Weiss via cctalk wrote:
>>> ...
>> 
>> As far as the DSK format, the files from at Alan’s site are logical
>> disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
>> Track 1.  In this case track 0 is ignored.
>> 
>> This is what RT-11 expects and uses for Logical Disks (LD:).
>> I’ve used Kermit and FTP to copy this file from my OSX disk to
>> a RT-11 DU type drive as a file. They mount and operate as
>> LD: drive without additional conversion.
>> 
>> 
>> SIMH on the other hand as I understand it, expects disk images to represent
>> the sectors of a disk.  I did a few checks and its appears faithful to the 
>> RX02 format.
>> It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors
>> for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
>> of zero to the above file to get things started. But this is not the entire 
>> story.
>> 
>> $  dd of=pad.dsk if=/dev/zero bs=256 count=26
>> 6656 bytes transferred in 0.000230 secs
>> $  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
>>  When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the 
>> expected
>> boot block is visible as (RT-11) Block #0.
>> 
>> .dump/rad50/ascii/end:0 dy:/term
>> DY:/X/E:0
>> BLOCK NUMBER  00
>> 000/ 000240 05 000404 00 00 041420 116020 000400 * 
>> ..C*
>>   D   E FT  J*HX82 FP
>> 020/ 004067 44 15 00 005000 041077 047517 026524 
>> *7.$...?BOOT-*
>>  ALW  6  M   AX JW9L$WGJD
>> 040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot 
>> on vol*
>>  GJEQ2NO. Q3GEG.QZ1R6 QM9
>> 060/ 066565 006545 005012 000200 105737 177564 100375 112037 
>> *ume._.t.}…*
>> 
>> For an RT-11 Volume, the next logical block #1 should be the home block.  In 
>> this case,
>> its not. Instead it is found at block #7, but offset (early) -256. bytes 
>> from its normal location in the block.
>> The first directory block should start at block #6.  Here there directory 
>> blocks starting at block #3 and #4.
>> 
>> So the padding is not enough here.  The 6 sector skew and interleave 
>> implemented in the handler come
>> into play.  I haven’t looked at the code, but SIMH probably expects the disk 
>> to be sequential copies of
>> physical sectors for the floppy drives.  This makes sense, as the emulator 
>> presents them to the DY: handler
>> where it will de-skew the data.
>> 
>> Thus a DSK file representing logical blocks will not work for a floppy image 
>> in this case.
>> A small program can probably be written to skew/Interweave the data to make 
>> them usable directly in SIMH.
>> 
>> Images of most other DEC media probably don’t encounter the problem, as 
>> their device handler or driver doesn't
>> implement either skew or interleave directly.  Most of the ones I encounter 
>> leave that to the disk media formatting
>> and/or controller firmware.
>> 
>> 
>> Jerry
>> j...@ieee.org
>> 
> Jerry's analysis is spot on. What Alan generated on his site were 988. block 
> long logical container files, not RX02 device file images.
> 
> One could write a simple program that reads the binary ".DSK" file, and 
> implements the track 0 prepend, 2:1 sector interlave, and +6 sector track to 
> track offset to generate true ".RX2" disk images with the appropriate sector 
> interleaves, as an exact image of the RX02 media. This .RX2 file would be 
> mountable directly under SIMH (and presumably PDP11GUI) as an emulated RX02 
> device.
> 
> One simple (heh) way to do the conversion without having to do any 
> programming would be to use SIMH running RT11. Boot RT11 from some media (say 
> RL02) and then mount the .DSK file as an MSCP device image (MSCP supports 
> variable sized physical disks using logical block order). Then mount an RX02 
> device under RT11; it will use the native SIMH .RX2 file format. Then under 
> RT11 copy 988. blocks from the MSCP (DU) device to the RX02 (DY) device. RT11 
> thru its RX02 driver will handle all the low level details of skipping track 
> 0, sector-sector interleave, and track-track sector skew.
> 


I had just sent Ulrich a new copy of TCPIPM.DSK created using SIMH  to bridge 
between Logical disk images and Sector image files when Don’s note came in.
Ulrich reports that he was able download file attached via RY created in SIMH 
via PDP11GUI to a real RX02. He then was able to successfully read the files.   

Thanks to Don and others who sent in pointers that helped us sort this process 
out.   

Jerry
j...@ieee.org

Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 14, 2017, at 11:49 PM, Glen Slick via cctalk  
> wrote:
> 
> On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk
>  wrote:
>> Hi all,
>> 
>> maybe someone can help.
>> I would like to install TCP/IP on my RT-11 system.
>> After a short search I have found the following, which I would use:
>> http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
>> But the images are in DSK format, but I can't write them with PDP11GUI,
>> which is the only way I have at the moment.
> 
> I would take a quick look at those .DSK images to see what I can make
> of them, but none of the download links on that page work for me.
> 
> For example, I can't download this .DSK image. Do these links work for
> other people?
> ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk

Glen - Try this link  ftp://shop-pdp.net/pub/tcpip/tcpip/tcpipm.dsk

As far as the DSK format, the files from at Alan’s site are logical
disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
Track 1.  In this case track 0 is ignored. 

This is what RT-11 expects and uses for Logical Disks (LD:). 
I’ve used Kermit and FTP to copy this file from my OSX disk to
a RT-11 DU type drive as a file. They mount and operate as 
LD: drive without additional conversion.


SIMH on the other hand as I understand it, expects disk images to represent
the sectors of a disk.  I did a few checks and its appears faithful to the RX02 
format.
It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors 
for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
of zero to the above file to get things started. But this is not the entire 
story.

$  dd of=pad.dsk if=/dev/zero bs=256 count=26
6656 bytes transferred in 0.000230 secs
$  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
 
When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the 
expected
boot block is visible as (RT-11) Block #0.

.dump/rad50/ascii/end:0 dy:/term
DY:/X/E:0
BLOCK NUMBER  00
000/ 000240 05 000404 00 00 041420 116020 000400 * 
..C*
  D   E FT  J*HX82 FP
020/ 004067 44 15 00 005000 041077 047517 026524 
*7.$...?BOOT-*
 ALW  6  M   AX JW9L$WGJD
040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot on 
vol*
 GJEQ2NO. Q3GEG.QZ1R6 QM9
060/ 066565 006545 005012 000200 105737 177564 100375 112037 
*ume._.t.}…*

For an RT-11 Volume, the next logical block #1 should be the home block.  In 
this case,
its not. Instead it is found at block #7, but offset (early) -256. bytes from 
its normal location in the block.   
The first directory block should start at block #6.  Here there directory 
blocks starting at block #3 and #4.

So the padding is not enough here.  The 6 sector skew and interleave 
implemented in the handler come
into play.  I haven’t looked at the code, but SIMH probably expects the disk to 
be sequential copies of 
physical sectors for the floppy drives.  This makes sense, as the emulator 
presents them to the DY: handler
where it will de-skew the data.  

Thus a DSK file representing logical blocks will not work for a floppy image in 
this case.  
A small program can probably be written to skew/Interweave the data to make 
them usable directly in SIMH.

Images of most other DEC media probably don’t encounter the problem, as their 
device handler or driver doesn't
implement either skew or interleave directly.  Most of the ones I encounter 
leave that to the disk media formatting
and/or controller firmware.


Jerry
j...@ieee.org

Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 13, 2017, at 12:59 PM, Ulrich Tagge  wrote:
> 
> Hi Jerry,
> 
> I have tried with PDP11GUI, but the first message says "The image contains 
> only 505856 bytes, but disk has 512512 bytes".
> I have written some disks, and have ignored this message, but none of them is 
> readable under RT-11.
> .dir dy0:
> ?DIR-F-Error reading directory
> 
> So I think the DSK format is different from the one PDP11GUI uses.
> In the documentation I have seen, that the format is the same as SimH uses.
> >>
> Image file format
> Every DEC disk or tape is logically represented as a linear list of “blocks”. 
> The block size differs between 128 byte and 1024 bytes. Reading and writing 
> is based on block numbers.
> The file format is that of SimH: a file image is just a stream of blocks.
> >>
> 
> Kermit would be a possibility, and I will try it later on.
> 
> Many Greetings
> Ulrich
> 

DEC OS’es typically do not do anything with track 0 on an RX02, and start with 
track 1.  I can only guess that PDP11GUI is trying to use the entire disk.

If there is an option to start at track 1 or skip the first 30 (?) blocks, that 
might work.


Note that ?DIR–F–Error reading directory is a hardware error.  
Bad data would instead cause a ?DIR–F–Invalid directory.
 

Regards,
Jerry

Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 13, 2017, at 11:00 AM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi all,
> 
> maybe someone can help.
> I would like to install TCP/IP on my RT-11 system.
> After a short search I have found the following, which I would use: 
> http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
> But the images are in DSK format, but I can't write them with PDP11GUI, which 
> is the only way I have at the moment.
> I like the PDP11GUI implementation and way, as there is nothing more you need 
> as a PDP and a RX02, which is in most cases available.
> 
> Someone here, who has the equipment, time and mind to write the DSK files 
> onto RX02 followed by an new image via PDP11GUI?
> Or is there any other suitable way for me?
> 
> 

Hi Ulrich,

I haven’t used PDP11GUI, but you should be able to use it write the DSK files 
from PC to an RX02.   Did you
encounter some problem?Alan has provided images which are RX02 sized.  This 
site has the latest distribution
http://shop-pdp.net/rthtml/tcpip.php

Otherwise - check this site for a copy of kermit - 
http://www.columbia.edu/kermit/pdp11.html
Note especially, the bootstrap process for RT-11.  You basically copy the files 
as text down to the machine.  
Then you compile a macro program to convert the .HEX file to a program. That 
minimal
kermit will then allow you load other data and programs, including the full 
featured Kermit-11.  

I’ve used this process myself using any basic terminal emulator. 
Paste the text via either an editor or using COPY TT: to DK:FILE.TXT  
(terminate with a CONTROL-Z). 

Jerry
j...@ieee.org

Re: PDP-11/84 Bootstrap for TSV05 (Dilog DU142)

[Jerry Weiss via cctalk]

> On Aug 9, 2017, at 1:58 PM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi All,
> I have some trouble to get the Bootstrap for an Dilog DU142 (TS11) Controller 
> running on my PDP-11/84.
> The bootstrap on page 3-2 of the following documentation was used: 
> http://bitsavers.informatik.uni-stuttgart.de/pdf/dilog/2120-0090-1_DU142_Jul87.pdf
> That's, what I have saved to the 11/84 PROM:
> 
> Type a command then press the RETURN key: 13
> Edit/create an EEPROM boot
> Type CTRL Z to exit or press the RETURN key for No change
> 1741 Bytes free in the EEPROM
> Device name = MSNew =
> Beginning  address  = 001000New =
> Last byte address   = 001120New =
> Start address   = 001000New =
> Highest Unit number = 1 New =
> Device Description  = TSV05 New =
> Enter ROM ODT
> 
> xx/ = open word location xx if address even, byte if odd
> RETURN  = close location
> . or LF = close location and open next
> -   = close location and open previous
> 
> ROM ODT> 001000/012700
> ROM ODT> 001002/172520
> ROM ODT> 001004/012701
> ROM ODT> 001006/172522
> ROM ODT> 001010/005011
> ROM ODT> 001012/105711
> ROM ODT> 001014/100376
> ROM ODT> 001016/012710
> ROM ODT> 001020/001066
> ROM ODT> 001022/105711
> ROM ODT> 001024/100376
> ROM ODT> 001026/012710
> ROM ODT> 001030/001106
> ROM ODT> 001032/105711
> ROM ODT> 001034/100376
> ROM ODT> 001036/012710
> ROM ODT> 001040/001106
> ROM ODT> 001042/105711
> ROM ODT> 001044/100376
> ROM ODT> 001046/005711
> ROM ODT> 001050/100422
> ROM ODT> 001052/012704
> ROM ODT> 001054/001102
> ROM ODT> 001056/005000
> ROM ODT> 001060/005007
> ROM ODT> 001062/046523
> ROM ODT> 001064/140004
> ROM ODT> 001066/001074
> ROM ODT> 001070/00
> ROM ODT> 001072/10
> ROM ODT> 001074/001116
> ROM ODT> 001076/00
> ROM ODT> 001100/16
> ROM ODT> 001102/00
> ROM ODT> 001104/140001
> ROM ODT> 001106/00
> ROM ODT> 001110/00
> ROM ODT> 001112/001000
> ROM ODT> 001114/00
> ROM ODT> 001116/00
> 
> That's the outcome.
> 
> Type a command then press the RETURN key: B MS0
> Trying MS0
> 001120
> @
> 
> I have also tried the native TS11 bootstraps, but they are also not working, 
> but this is more likely related to the Dilog.
> Any help would be appreciated, as I can't wait to boot from my fresh build 
> RT-11 Tapes.
> By the way, RT-11 recognized this controller, and is able to read and write 
> to the TS05 Drive.
> 
> .show de:ms
> 
> Device Status CSR Vector(s)
> -- -- --- -
> MS Installed 172522 224 300
> 
> Many Greetings
> Ulrich


The first thing I would do is check the contents of 1000-1116 after the halt 
occurs
against the what you have in the eeprom.

1120 is not a location I would expect this to halt, so either there is a 
problem in
loading the the eeprom bootstrap or perhaps the first records of the tape are 
being loaded.
Do you see any tape motion?

For RT-11, you need to load device specific files at the beginning of the tape.
The tape primary and secondary bootstrap which load the monitor, need to be 
first.
The following (rough) example is for  MS:  @1600BPI and the RT11SJ monitor.

   Ini/Que/Vol/File:MBOT16.BOT MS: 
   Cop MSBOOT.BOT MS:/Pos:-1
   Cop MDUP.MSMS:/Pos:-1
   Cop SWAP.SYS   MS:/Pos:-1
   Cop RT11SJ.SYS MS:/Pos:-1
   Cop MS.SYS MS:/Pos:-1
   Cop DU.SYS MS:/Pos:-1
   Cop MDUP.SAV   MS:/Pos:-1
   Cop PIP.SAVMS:/Pos:-1
   Cop DUP.SAVMS:/Pos:-1

… + other OS files. 


Jerry
j...@ieee.org

Re: WTB: RX02 Floppy Disks

[Jerry Weiss via cctalk]

> On Aug 4, 2017, at 1:09 PM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi Jerry,
>> You’ve made pretty good progress.
> Yes with the right input and help this can happen. ;-)
> And all the help is much appreciated!

Glad to share.

>> 
>> If you haven’t already, Google for and look at the manual for the SQ739. I 
>> think you will find that most of the
>> commands for the on-board diagnostics are the same.  The unibus controller 
>> will have a
>> different layout and perhaps a physical vector switch, but you should be 
>> able to sort out the differences.
>> 
> Not done by now, but is now noted and on the plan for the weekend, I'm also 
> interested to know about the jumper settings as there are some of them

Fortunately the vendor likely used the same firmware for several models and 
across Q + Unibus.  

> .
>> 
>> What version of RT11 do you have?  The later versions would show the
>> CSR that the hander is set to.
> Its: RT-11SJ (S) V04.00I ... quite old.

Each different version of RT11 has its own charms.   In V4 the device handler 
was no longer
bound directly to the OS Monitor.  No more compiling a new monitor for each new 
device.

> 
>>  
>> You mention a RC25.  Is that on another machine? If you have two MSCP
>> controllers in the same backplane (KLESI? + SU723) then that is more complex.
>> 
>> My guidance below assumes the SU723 and a bootable RX02 device are
>> the only disks.  Do not follow if you have two MSCP controllers installed.
> That's the right assumption, I have two /84 one with lesi and working RC25 
> where I have created the Floppy disks, and a playground mostly empty, but now 
> equipped with SCSI and RX211.
>> The address 160340 is not what is normally expected “standard” CSR for a 
>> MSCP.
>> Its is easy to change the handler address.
>> 
>> First make a copy of the DU.SYS handler to preserve it.
>> 
>>copy/sys du.sys duorg.sys
> Done
>> The set the CSR that you are using
>> 
>>set du csr=160340
> Output:
> .SET DU CSR=17760340
> ?DU-W-Patch handler bootstrap, put CSR at 3264

As you may have already learned, use only 16bit addresses for this.

> 
>> Try vector address 154 first, unless you know the board is configured 
>> differently.
>> It appears already set for this, but here is how you change it.
>> 
>>set du vector=154
> Output:
> .SET DU VECTOR=154
> 
> .
>> You should then be able to install and load the handler.
>> 
>> install du
> Output:
> .INSTALL DU
> .
>> load du
> Output:
> .LOAD DU
> 
>> Depending on the DU handler, it is possible to map a large MSCP image to 
>> multiple
>> partitions.  If the handler installs, try the following.  It show a basic 
>> mapping.
>> Single controller, single drive and in this case 8 partitions.   The first 
>> partition
>> should be the same as below.  An RZ22 would normally only have space
>> sufficient for 1 partition.
>> 
>> show de:du
>> 
>> DeviceStatus   CSR Vector(s)
>>-- --   ---
>> -
>>  DU Resident172150   154
>> 
>>  DU0: is set PORT =  0, UNIT =  0, PART =  0
>>  DU1: is set PORT =  0, UNIT =  0, PART =  1
>>  DU2: is set PORT =  0, UNIT =  0, PART =  2
>>  DU3: is set PORT =  0, UNIT =  0, PART =  3
>>  DU4: is set PORT =  0, UNIT =  0, PART =  4
>>  DU5: is set PORT =  0, UNIT =  0, PART =  5
>>  DU6: is set PORT =  0, UNIT =  0, PART =  6
>>  DU7: is set PORT =  0, UNIT =  0, PART =  7
> Output:
> .SHOW DE:DU
> ?KMON-F-Illegal command
> .SHOW DEV:DU
> ?KMON-F-Illegal command
> 
> (RT11 Version to old?)

Yes, bummer but not a blocking gap.

> 
> 
> .SHOW DEV
> 
> Device  Status   Vector
> ---
>  US  Not installed  410
>  DL  Not installed  160
>  RK  Not installed  220
>  DY  Resident   264
>  DX  Not installed  264
>  LP  146676 200 204
>  SC  143332 000
>  HC  Not installed  330 334
>  BS  Not installed  300 304
>  VW  Not installed  270 274
>  NL  Installed  000
>  LS  Installed  200 204
>  MS  Not installed  224
>  MM  Not installed  224
> *  DU  141440 154*
> 
> So something happens and we have a first progress.
> 
>> Since you already did a SCSI format from the controller or if the drive
>> was previously formatted, you will not need to repeat this. The RT11 FORMAT
>> command does NOT support this as an MSCP device.  Note: the handler can be
>> configured to more partitions and disk space than actually exist on the 
>> drive.
>> 
>> You can examine the contents of the drive to see if it readable.
>> 
>> dump/term du0:/end:1
> Dump is unfortunately not available on my disk by 

Re: WTB: RX02 Floppy Disks

[Jerry Weiss via cctalk]

> On Aug 3, 2017, at 4:28 PM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi All,
> All my 8" SSDD /SSSDdisks are non formatted, which was the reason for my 
> initial troubles.
> Nevertheless, my IBM System /23 (Type 5324) can format disks in three 
> different formats:
> 
> _1. IBM System /23 Format_
> 512 Bytes per Sector
> Possible Disk: SSSD, SSDD, DSDD
> 
> _2. Standard Format_
> 128 Bytes per Sector
> Possible Disk: SSSD, SSDD
> 
> _3. H- Format_
> 258 Bytes per Sector
> Possible Disk: DSDD
> 
> _So option 2_ was the right one, also when nothing in the docs point to the 
> IBM 3740 format.
> After booting the System/23 with the inserted maintenance Disk VOL002 the 
> formatter program can be started with the following command: link prepare
> 
> 
> By now I have 20 RX02 Disks formatted, and was also able to create a bootable 
> RT11 Disk via my running RT11 installation on my RC25.
> It is RT-11SJ (S) V04.00I ...
> >>>
> .FORMAT DY1:
> DY1:/FORMAT-Are you sure?Y
> ?FORMAT-I-Formatting complete
> <<<
> >>>
> .INIT/BAD DY1:
> DY1:/Initialize; Are you sure? Y
> ?DUP-I-No bad blocks detected DY1:
> <<<
> 
> Next step would be to install RT11 on my SCSI Disk, which is presented 
> through a Dilog SU726A as MSCP Device 0 (Address 160340 (will be 1760340 on 
> my PDP-11/84)) to the system.
> Disk is an DEC RZ22 and was also formatted and mapped, through the Dilog 
> "BIOS" (Jumper J14 in to boot Maintenance Address ... and @175000g followed 
> by FT)
> Now it looks like I need the SU726A manual, as I have no clue as which device 
> RT11 should recognize the Dilog, I assume DU0: but RT11 doesn't load the 
> Device.
> 

Hi Ulrich,
You’ve made pretty good progress.

If you haven’t already, Google for and look at the manual for the SQ739. I 
think you will find that most of the 
commands for the on-board diagnostics are the same.  The unibus controller will 
have a 
different layout and perhaps a physical vector switch, but you should be able 
to sort out the differences. 



> *SHOW DEV*
> 
> Device  Status   Vector
> ---
>  US  Not installed  410
>  DL  Not installed  160
>  DU  Not installed  154
>  RK  Not installed  220
>  DY  Resident   264
>  DX  Not installed  264
>  LP  146676 200 204
>  SC  143332 000
>  HC  Not installed  330 334
>  BS  Not installed  300 304
>  VW  Not installed  270 274
>  NL  Installed  000
>  LS  Installed  200 204
>  MS  Not installed  224
>  MM  Not installed  224

What version of RT11 do you have?  The later versions would show the 
CSR that the hander is set to.   

You mention a RC25.  Is that on another machine? If you have two MSCP 
controllers in the same backplane (KLESI? + SU723) then that is more complex.

My guidance below assumes the SU723 and a bootable RX02 device are
the only disks.  Do not follow if you have two MSCP controllers installed.

> 
> 
> 
> Any Hint how I get RT11 load the correct device so that I can format and init 
> the SCSI Disk?
> Is maybe Someone here with an Manual of the Dilog? A SU723 could be also 
> helpful, …


The address 160340 is not what is normally expected “standard” CSR for a MSCP. 
Its is easy to change the handler address.

First make a copy of the DU.SYS handler to preserve it.

   copy/sys du.sys duorg.sys 

The set the CSR that you are using

   set du csr=160340

Try vector address 154 first, unless you know the board is configured 
differently.
It appears already set for this, but here is how you change it.

   set du vector=154

You should then be able to install and load the handler.

install du
load du

Depending on the DU handler, it is possible to map a large MSCP image to 
multiple
partitions.  If the handler installs, try the following.  It show a basic 
mapping.
Single controller, single drive and in this case 8 partitions.   The first 
partition
should be the same as below.  An RZ22 would normally only have space
sufficient for 1 partition.

show de:du

DeviceStatus   CSR Vector(s)
   -- --   ----
 DU Resident172150   154

 DU0: is set PORT =  0, UNIT =  0, PART =  0
 DU1: is set PORT =  0, UNIT =  0, PART =  1
 DU2: is set PORT =  0, UNIT =  0, PART =  2
 DU3: is set PORT =  0, UNIT =  0, PART =  3
 DU4: is set PORT =  0, UNIT =  0, PART =  4
 DU5: is set PORT =  0, UNIT =  0, PART =  5
 DU6: is set PORT =  0, UNIT =  0, PART =  6
 DU7: is set PORT =  0, UNIT =  0, PART =  7

Since you already did a SCSI format from the controller or if the drive 
was previously formatted, you will not need to repeat this. The