date:20160312

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North


Ok, filed as: https://github.com/simh/simh/issues/285

On 3/12/2016 11:14 PM, Don North wrote:

Fixed!

sim> set cpu 11/34 256K fpp
sim> set tdc enable
sim> attach tdc0 tu58.dsk
sim> b tdc0

BOOTING UP XXDP-XM EXTENDED MONITOR

XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DD0
124KW OF MEMORY
UNIBUS SYSTEM

RESTART ADDRESS: 152000
TYPE "H" FOR HELP !

In file pdp11_td.c, comment out/delete line 1023 (red) "ctlr->rx_buf = 
ctlr->obuf[ctlr->obptr++];   /* get first byte */"


This would seem to be priming the read routine, but in fact it is discarding 
the first byte of the block zero bootstrap.


Don


case TD_OPBOO:
if (ctlr->ibptr < 2) {  /* whole packet read? */
ctlr->ilen = 2;
ctlr->o_state = TD_GETDATA; /* get rest of packet */
return;
}
else {
int8 *fbuf;
int i;

sim_debug (TDDEB_TRC, ctlr->dptr, "td_process_packet(OPBOO) 
Unit=%d\n", ctlr->ibuf[4]);

ctlr->unitno = ctlr->ibuf[1];
fbuf = ctlr->uptr[ctlr->unitno].filebuf;
ctlr->block = 0;
ctlr->txsize = 0;
ctlr->p_state = TD_READ2;
ctlr->offset = 0;
ctlr->obptr = 0;

for (i=0; i < TD_NUMBY; i++)
ctlr->obuf[i] = fbuf[i];
ctlr->olen = TD_NUMBY;
//  ctlr->rx_buf = ctlr->obuf[ctlr->obptr++];   /* get first byte */
sim_data_trace(ctlr->dptr, >uptr[ctlr->unitno], ctlr->obuf, 
"Boot Block Data", ctlr->olen, "", TDDEB_DAT);

sim_activate (ctlr->uptr+ctlr->unitno, td_ctime);/* sched command */
}
break;

case TD_OPCNT:
break;







On 3/12/2016 10:19 PM, Don North wrote:

So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(930594)> TDC DAT: 0180 B4 FE C3 00 FF 8B AC FE FD 80 87 00 03 0A CF 09 

DBG(930594)> TDC DAT: 0190 FF 8B 9C FE FD 80 C5 1F 98 FE E5 81 43 D1 C3 00 
C...
DBG(930594)> TDC DAT: 01A0 87 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North


Fixed!

sim> set cpu 11/34 256K fpp
sim> set tdc enable
sim> attach tdc0 tu58.dsk
sim> b tdc0

BOOTING UP XXDP-XM EXTENDED MONITOR

XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DD0
124KW OF MEMORY
UNIBUS SYSTEM

RESTART ADDRESS: 152000
TYPE "H" FOR HELP !

In file pdp11_td.c, comment out/delete line 1023 (red) "ctlr->rx_buf = 
ctlr->obuf[ctlr->obptr++];   /* get first byte */"


This would seem to be priming the read routine, but in fact it is discarding the 
first byte of the block zero bootstrap.


Don


case TD_OPBOO:
if (ctlr->ibptr < 2) {  /* whole packet read? */
ctlr->ilen = 2;
ctlr->o_state = TD_GETDATA; /* get rest of packet */
return;
}
else {
int8 *fbuf;
int i;

sim_debug (TDDEB_TRC, ctlr->dptr, "td_process_packet(OPBOO) 
Unit=%d\n", ctlr->ibuf[4]);

ctlr->unitno = ctlr->ibuf[1];
fbuf = ctlr->uptr[ctlr->unitno].filebuf;
ctlr->block = 0;
ctlr->txsize = 0;
ctlr->p_state = TD_READ2;
ctlr->offset = 0;
ctlr->obptr = 0;

for (i=0; i < TD_NUMBY; i++)
ctlr->obuf[i] = fbuf[i];
ctlr->olen = TD_NUMBY;
//  ctlr->rx_buf = ctlr->obuf[ctlr->obptr++];   /* get first byte */
sim_data_trace(ctlr->dptr, >uptr[ctlr->unitno], ctlr->obuf, 
"Boot Block Data", ctlr->olen, "", TDDEB_DAT);

sim_activate (ctlr->uptr+ctlr->unitno, td_ctime);/* sched command */
}
break;

case TD_OPCNT:
break;







On 3/12/2016 10:19 PM, Don North wrote:

So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(930594)> TDC DAT: 0180 B4 FE C3 00 FF 8B AC FE FD 80 87 00 03 0A CF 09 

DBG(930594)> TDC DAT: 0190 FF 8B 9C FE FD 80 C5 1F 98 FE E5 81 43 D1 C3 00 
C...
DBG(930594)> TDC DAT: 01A0 87 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

DBG(930594)> TDC DAT: 01B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North


So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(930594)> TDC DAT: 0180 B4 FE C3 00 FF 8B AC FE FD 80 87 00 03 0A CF 09 

DBG(930594)> TDC DAT: 0190 FF 8B 9C FE FD 80 C5 1F 98 FE E5 81 43 D1 C3 00 
C...
DBG(930594)> TDC DAT: 01A0 87 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

DBG(930594)> TDC DAT: 01B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 01C0 thru 01FF same as above
DBG(930597)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
DBG(930597)> TDC IRD: RX_CSR: DONE0 IE0
DBG(930599)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...
DBG(930763)> TDC IRD: RX_CSR: DONE1 IE0
DBG(930765)> TDC RRD: td_rd(PA=17776502(RX_BUF), access=0-Read)
DBG(930765)> TDC IRD: RX_BUF: ERR0 OVR0 RBRK0DAT=0x00 
<---DATA=00

DBG(930767)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...
DBG(930943)> TDC IRD: RX_CSR: DONE1 IE0
DBG(930945)> TDC RRD: td_rd(PA=17776502(RX_BUF), access=0-Read)
DBG(930945)> TDC IRD: RX_BUF: ERR0 OVR0 RBRK0 DAT=0x20 
<---DATA=20

DBG(930947)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
DBG(930947)> TDC IRD: RX_CSR: DONE0 IE0
DBG(930949)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...



On 3/12/2016 9:47 PM, Don North wrote:
I've been doing some testing on the (new) SIMH TU58 device, and am finding 
that reading the boot block does not work.


I have TU58 bootable images, and when I try and boot from them in SIMH they 
halt/crash.


I adapted my PDP-11 M(312 TU58 boot code to a loadable SIMH image, and found 
that it appears that the TU58 boot command in SIMH (which should read block 
zero of the selected unit into memory locations 0-777(8)) is skipping over the 
first byte in the boot block (the 240(8) byte that is part of the NOP in the 
first word of every DEC bootstrap).


If I dump the first section of the bootable .dsk image I see:

local[505] od -b -N512 -v tu58.dsk
000 240 000 040 001 006 000 000 000 012 000 000 000 000 000 000 000
020 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North

I've been doing some testing on the (new) SIMH TU58 device, and am finding that 
reading the boot block does not work.


I have TU58 bootable images, and when I try and boot from them in SIMH they 
halt/crash.


I adapted my PDP-11 M(312 TU58 boot code to a loadable SIMH image, and found 
that it appears that the TU58 boot command in SIMH (which should read block zero 
of the selected unit into memory locations 0-777(8)) is skipping over the first 
byte in the boot block (the 240(8) byte that is part of the NOP in the first 
word of every DEC bootstrap).


If I dump the first section of the bootable .dks image I see:

local[505] od -b -N512 -v tu58.dsk
000 240 000 040 001 006 000 000 000 012 000 000 000 000 000 000 000
020 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
040 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
060 000 000 000 000 000 000 000 000 002 012 002 000 000 000 000 000
100 000 002 010 000 306 025 000 140 005 000 303 025 060 000 302 025
120 003 000 123 020 321 013 302 012 374 002 346 027 004 000 337 025

but when I give the 'boot' opcode to the emulated TU58 in SIMH it returns:

+:  000 040 001 006 000 000 000 012 000 000 000 000 000 000 000 000
+0020:  000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
+0040:  000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
+0060:  000 000 000 000 000 000 000 002 012 002 000 000 000 000 000 000
+0100:  002 010 000 306 025 000 140 005 000 303 025 060 000 302 025 003
+0120:  000 123 020 321 013 302 012 374 002 346 027 004 000 337 025 152

By inspection the bytes are the same, just shifted down one location from
where they should be, and the 240(8) byte in location zero is missing.

So this is why 'boot tdc0' fails in the current SIMH on github.

PDP-11 simulator V4.0-0 Betagit commit id: b304d7f4
Disabling XQ
TDC: buffering file in memory
Debug output to "tdc.log"
PDP-11 simulator V4.0-0 Beta
Simulator Framework Capabilities:
32b data
32b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 2
Host Platform:
Compiler: GCC 5.3.0
Simulator Compiled: Mar 12 2016 at 16:36:37
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: CYGWIN_NT-6.1-WOW lenovoS30w7 2.4.1(0.293/5/3) 2016-01-24 
11:24 i686 Cygwin

git commit id: b304d7f4
PDP-11 simulator configuration



On 3/12/2016 3:58 PM, Don North wrote:
Whoops slight correction .. . the TU58 protocol supports a 16b block number, 
so it is 65536 blocks of 512B, or 32MB maximum.


On 3/12/2016 3:55 PM, Don North wrote:

Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment 
dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the 
virtual TU58 (as one can do with a real TU58) but it does not appear to work 
as I expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and 
then do read-only accesses to the full image. The real TU58 protocol supports 
up to 32MB devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 
only supports a physical TU58 tape image of 256KB. I'll have to do some more 
experiments and read some code to see what is going on.


If this restriction is in place it does rather significantly limit the 
utility of the TU58 virtual serial device, in not allowing one to build an 
(up to) 32MB disk image under SIMH, and then move it to a real TU58. Limiting 
simh to only 256KB sized images is being true to the physical limitation of 
TU58 cartridges, but not true to the actual capability of the TU58 serial 
line protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:
I had a little time after lunch to try the below procedure and using the 
beta version of SIMH I am able to create a tape image that's bootable by 
SIMH without the below error.


I copied the following to the image, which I will try with TU58em when I get 
home tonight:


DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind  wrote:


SIMH has never directly supported

Type 270 disk file on PDP-6

2016-03-12 Thread Eric Smith

I just was looking at the I/O device code assignments in the 1973
DECsystem-10 System Reference Manual, and happened to notice the entry
for the Type 270 disk file used on the PDP-6.

PDP-6 and PDP-10 device codes are three octal digits, of which the
third digit can only be 0 or 4.

The device code for the Type 270 is octal 270.  Coincidence?  :-)

Re: A gold mine for anybody in Austin...

2016-03-12 Thread James Vess

I'm in Houston and could make the trip, Anyone here interested in the
systems listed?

I would need to see enough interest to go do it though, as even though I'd
love to get these and just play with them, but I wouldn't be able to keep
them.

I can't let myself go nuts collecting as I'm living the apartment life and
I don't want to "have to sell" things when I don't want to due to space
constraints or moving.

On Sat, Mar 12, 2016 at 5:24 PM, Ali  wrote:

> > Unfortunately, I'm nowhere near Austin! But here is a great gold mine
> > for somebody local http://austin.craigslist.org/sys/5436553322.html
>
> Sounds fishy/weird? He can only recall having two (maybe more) Next
> systems but he wants to sell everything in his house and garage for $600 to
> make room? At the same time he is willing to take trade so kind of seems
> self defeating.
>
> I guess if you are in Austin and have time this weekend it is worth a
> look.
>
> -Ali
>
>

Re: Sun 4/260

2016-03-12 Thread James Vess

Thanks Mattis! I'm going to give him a follow.

It's been hard to find these systems or even cards anymore on Ebay, it went
from a few then fell to none.
I usually filter international though, so I don't have any insight there.
Part of why I really appreciate you providing that!

Maybe the spring Garage clean outs will get more that stuff flushed on to
Ebay this year ;) Just in time for me to find a new system to require parts
for.

On Sat, Mar 12, 2016 at 4:08 AM, Mattis Lind  wrote:

> 2016-03-12 9:56 GMT+01:00 James Vess :
>
> > Howdy there folks,
> >
> > I've been kicking myself for giving away a dying Sun4/260 due to space
> > issues and moving about 15 years ago and since then my life has settled
> > I've started looking occasionally to see if I can find another one.
> >
> > Has anyone seen any of these units in a workable condition that are for
> > sale or possibly even loan?
> >
>
> There is someone in the UK that sells a lot of parts from a 4/2xx machine:
>
> http://www.ebay.co.uk/itm/161997957466
>
> /Mattis
>
>
> >
> > I never got a good chance to dig into the one I had and I regret it, just
> > looking to recoup lost time :)
> >
> > Thanks,
> > James
> >
>

Re: Sun 4/260

2016-03-12 Thread James Vess

I honestly am a bit surprised, as other dealings I've had with groups that
focus on technology typically are not as welcoming or responsive.

Thanks! It's a great start to my future w/ classiccmp ;)

Al, I'm in Texas so I'm not too far away.
Given the unit's size, I'd need to do local pickup ( unless you have some
super sweet freight deal that I'm unaware of ) and that shouldn't be an
issue?

I've been meaning to do a road trip that direction or I have a friend who
would likely be willing to run by and grab it ( He's in Utah ) on a weekend.

Just let me know what you have and what you're looking for in return and
I'll see what I can do!

On Sat, Mar 12, 2016 at 10:35 AM, Al Kossow  wrote:

>
>
> On 3/12/16 12:56 AM, James Vess wrote:
>
>> Howdy there folks,
>>
>> I've been kicking myself for giving away a dying Sun4/260 due to space
>> issues and moving about 15 years ago and since then my life has settled
>> I've started looking occasionally to see if I can find another one.
>>
>>
> Where are you?
>
> I have a pair of 280 series servers in racks and a 3 or 4/260 that I'm in
> the process of pulling out of storage along with a LOT of 9u boards in the
> SF bay area. They are going to be available before April.
>
> I am not willing to handle shipping beyond having someone pick them up.
>
>
>

Introduction and Alpha Micro AM-1200 query

2016-03-12 Thread Ross Sponholtz

Hi Everyone,
I just subscribed on the cctalk mailing list, I thought I’d introduce myself.  
The first computer that I ever used was an Alpha Micro AM-100 at my high 
school, where I had the extra project of figuring out Pascal and explaining it 
to the teacher.  I’m pretty excited about Eric and Al’s decapping project – I’m 
imagining a FPGA-based AM-100 emulator in the future!

In fact, I recently picked up an Alpha Micro AM-1200 that I’d like to get 
running. It’s giving a selftest error indicating a memory problem that 
hopefully I can figure out how to track down.  After that, I’ll need to get an 
OS on an appropriate disk (I don’t think the disk is working).  Does anyone 
here have any info or documentation on these machines, or maybe even some 
software? The info out on the ‘net on these things seems pretty minimal. 

Back to the intro: I went to University of Colorado Boulder for Computer 
Science back in the mid-80s, graduating in 88 after doing a lot of work under 
VMS and various Unix machines.  I now work for Microsoft (in cloud pre-sales 
tech), and have a small collection of old computers – AM-1200, Microvax, Mac SE 
and HP 9000/300.  I recently picked up a nice ADM-3a that I got working by 
replacing some RAM chips.  

Anyway, thanks for your help, and love the conversation!

Ross Sponholtz
rsponho...@hotmail.com

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North

Whoops slight correction .. . the TU58 protocol supports a 16b block number, so 
it is 65536 blocks of 512B, or 32MB maximum.


On 3/12/2016 3:55 PM, Don North wrote:

Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment 
dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the 
virtual TU58 (as one can do with a real TU58) but it does not appear to work 
as I expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and 
then do read-only accesses to the full image. The real TU58 protocol supports 
up to 32MB devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 
only supports a physical TU58 tape image of 256KB. I'll have to do some more 
experiments and read some code to see what is going on.


If this restriction is in place it does rather significantly limit the utility 
of the TU58 virtual serial device, in not allowing one to build an (up to) 
32MB disk image under SIMH, and then move it to a real TU58. Limiting simh to 
only 256KB sized images is being true to the physical limitation of TU58 
cartridges, but not true to the actual capability of the TU58 serial line 
protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:
I had a little time after lunch to try the below procedure and using the beta 
version of SIMH I am able to create a tape image that's bootable by SIMH 
without the below error.


I copied the following to the image, which I will try with TU58em when I get 
home tonight:


DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind  wrote:


SIMH has never directly supported mounting/attaching virtual TU58 devices.
Altho the required serial interface
is emulated (ie, a plain DL11 at 776500/300) the TU58 drive behind the
serial interface has never been emulated.

I just tested the latest SimH from github and it is indeed possible to
enable tdc and attach an image file to the tdc0 device. I then booted into
RT11 from a DU-device and did INIT DD0: no problem.
Then I made a bootable DD image. I did even do a BOOT DD0: which gave me a
RT11-prompt. But booting from SimH failed on me. I am not sure why.

MattisMacBook:BIN mattis$ ./pdp11
PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: creating new file
TDC: buffering file in memory
sim> attach rq0 rt11v53-games.dsk
sim> b rq0

RT-11SJ  V05.03

.init dd0:
DD0:/Initialize; Are you sure? Y

.copy dd.sys dd0:
Files copied:
DK:DD.SYS  to DD0:DD.SYS
 Copying some files *


.copy rt11sj.sys dd0:
Files copied:
DK:RT11SJ.SYS  to DD0:RT11SJ.SYS

.copy/boot rt11sj.sys dd0:
.boot dd0:

RT-11SJ  V05.03

.dir

DD.SYS 5P 20-Dec-85  TT.SYS 2P 20-Dec-85
SWAP  .SYS27P 20-Dec-85  STARTS.COM 1P 20-Dec-85
DIR   .SAV19P 20-Dec-85  DUP   .SAV47P 20-Dec-85
DU.SYS 8P 20-Dec-85  RT11SJ.SYS79P 20-Dec-85
8 Files, 188 Blocks
316 Free blocks

.boot du0:


RT-11SJ  V05.03

.

Simulation stopped, PC: 146414 (BCC 146446)
sim> exit
Goodbye
TDC: writing buffer to file

PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: buffering file in memory
sim> b tdc0


Trap stack push abort, PC: 00 (WAIT)
sim>

I have no idea why SimH is not able to boot from the simulated DD0: device.
The steps to make a bootable dd0: was exactly the same steps as to make a
bootable RK0: which works just fine.


Ersatz-11 on the other hand works fine with the same image:

E11>assign tt1: dda:
E11>mount dda0: rt11v53_dd.dsk
E11>b tt1:

RT-11SJ  V05.03

.dir

TT.SYS 2P 20-Dec-85  DD.SYS 5P 20-Dec-85
RT11SJ.SYS79P 20-Dec-85  SWAP  .SYS27P 20-Dec-85
STARTS.COM 1P 20-Dec-85  DIR   .SAV19P 20-Dec-85
RESORC.SAV25P 20-Dec-85
7 Files, 158 Blocks
346 Free blocks

.


This is the image that boots in Ersatz-11 but not in SimH:
https://dl.dropboxusercontent.com/u/96935524/rt11v53_dd.dsk.gz
Since it boots on Ersatz-11 when set to 11/03 CPU it should work on the
real hardware.

BTW. It not so that the LTC interrupt is enabled in your system? I have had
problem with that one. In certain cases it need to be disabled. If I
remember correctly I had problems booting RT11 from MSCP devices with LTC
enabled.

/Mattis




Don

Re: Which RT-11 for an 11/03

2016-03-12 Thread Don North


Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the virtual 
TU58 (as one can do with a real TU58) but it does not appear to work as I 
expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and then do 
read-only accesses to the full image. The real TU58 protocol supports up to 32MB 
devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 only supports 
a physical TU58 tape image of 256KB. I'll have to do some more experiments and 
read some code to see what is going on.


If this restriction is in place it does rather significantly limit the utility 
of the TU58 virtual serial device, in not allowing one to build an (up to) 32MB 
disk image under SIMH, and then move it to a real TU58. Limiting simh to only 
256KB sized images is being true to the physical limitation of TU58 cartridges, 
but not true to the actual capability of the TU58 serial line protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:

I had a little time after lunch to try the below procedure and using the beta 
version of SIMH I am able to create a tape image that's bootable by SIMH 
without the below error.

I copied the following to the image, which I will try with TU58em when I get 
home tonight:

DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind  wrote:


SIMH has never directly supported mounting/attaching virtual TU58 devices.
Altho the required serial interface
is emulated (ie, a plain DL11 at 776500/300) the TU58 drive behind the
serial interface has never been emulated.

I just tested the latest SimH from github and it is indeed possible to
enable tdc and attach an image file to the tdc0 device. I then booted into
RT11 from a DU-device and did INIT DD0: no problem.
Then I made a bootable DD image. I did even do a BOOT DD0: which gave me a
RT11-prompt. But booting from SimH failed on me. I am not sure why.

MattisMacBook:BIN mattis$ ./pdp11
PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: creating new file
TDC: buffering file in memory
sim> attach rq0 rt11v53-games.dsk
sim> b rq0

RT-11SJ  V05.03

.init dd0:
DD0:/Initialize; Are you sure? Y

.copy dd.sys dd0:
Files copied:
DK:DD.SYS  to DD0:DD.SYS
 Copying some files *


.copy rt11sj.sys dd0:
Files copied:
DK:RT11SJ.SYS  to DD0:RT11SJ.SYS

.copy/boot rt11sj.sys dd0:
.boot dd0:

RT-11SJ  V05.03

.dir

DD.SYS 5P 20-Dec-85  TT.SYS 2P 20-Dec-85
SWAP  .SYS27P 20-Dec-85  STARTS.COM 1P 20-Dec-85
DIR   .SAV19P 20-Dec-85  DUP   .SAV47P 20-Dec-85
DU.SYS 8P 20-Dec-85  RT11SJ.SYS79P 20-Dec-85
8 Files, 188 Blocks
316 Free blocks

.boot du0:


RT-11SJ  V05.03

.

Simulation stopped, PC: 146414 (BCC 146446)
sim> exit
Goodbye
TDC: writing buffer to file

PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: buffering file in memory
sim> b tdc0


Trap stack push abort, PC: 00 (WAIT)
sim>

I have no idea why SimH is not able to boot from the simulated DD0: device.
The steps to make a bootable dd0: was exactly the same steps as to make a
bootable RK0: which works just fine.


Ersatz-11 on the other hand works fine with the same image:

E11>assign tt1: dda:
E11>mount dda0: rt11v53_dd.dsk
E11>b tt1:

RT-11SJ  V05.03

.dir

TT.SYS 2P 20-Dec-85  DD.SYS 5P 20-Dec-85
RT11SJ.SYS79P 20-Dec-85  SWAP  .SYS27P 20-Dec-85
STARTS.COM 1P 20-Dec-85  DIR   .SAV19P 20-Dec-85
RESORC.SAV25P 20-Dec-85
7 Files, 158 Blocks
346 Free blocks

.


This is the image that boots in Ersatz-11 but not in SimH:
https://dl.dropboxusercontent.com/u/96935524/rt11v53_dd.dsk.gz
Since it boots on Ersatz-11 when set to 11/03 CPU it should work on the
real hardware.

BTW. It not so that the LTC interrupt is enabled in your system? I have had
problem with that one. In certain cases it need to be disabled. If I
remember correctly I had problems booting RT11 from MSCP devices with LTC
enabled.

/Mattis




Don

RE: A gold mine for anybody in Austin...

2016-03-12 Thread Ali

> Unfortunately, I'm nowhere near Austin! But here is a great gold mine
> for somebody local http://austin.craigslist.org/sys/5436553322.html

Sounds fishy/weird? He can only recall having two (maybe more) Next systems but 
he wants to sell everything in his house and garage for $600 to make room? At 
the same time he is willing to take trade so kind of seems self defeating.

I guess if you are in Austin and have time this weekend it is worth a look.

-Ali

Re: Honneywell multics? from panels. the inline phots in this message folks...

2016-03-12 Thread David Griffith


On Sat, 12 Mar 2016, jim s wrote:


What is the provenance / source of the panels?

Mine came from an acquisition by Nick Allen from a collection in Georgia.  I
believe there was a Multics installation in Atlanta they were removed from.

The panels on the 6180 at USL were all inside side access panels for one of
the rows of hardware boxes. One box panel was usually exposed with the door
removed, but it could be closed up.  There were problems which required
access to one of the panels frequently in operations, so it was seldom
closed.

We probably could get access to Dockmaster with some advance arrangement and
good will on the part of the CHM when they have time to arrange access to
the storage to which  it was moved to see actual installed panels. 

I agree, the black panel has about the only interesting display.

+David Griffith

I might also suggest that once David Griffith finishes porting the PDP 10
Panda panel and has that design working and integrated that there may be
enough blink'n lights there to display a satisfying 6180 display on a normal
desktop case.

the advantage is that it is at least already 36 bits and has some of the
nonsense of having that bit count worked out already.  I'd think we
(someone) could fork and add a second bank of lights, or use two of the
Panda usb devices to put out a lot of information about a 72 bit 6180.

His main problem now is with interfacing and coding PDP 10 assembly code
which is obviously not useful for re-purposing it for Multics use anyway,
and is internal to SIMh PDP10 emulation.

If a lot of people who are interested in blinking Multics Honeywell 6180
displays were interested it would contribute a lot to him selling out a run
of his board kits.


Can I get a picture of the black panel you're referring to?  I already 
have a two-row variant of the Panda Display.  It exists as a branch at 
https://github.com/DavidGriffith/panda-display.  The single-row one was 
designed as a drop-in replacement for the parallel port version.  The 
layout of the double-row one can be more flexible.  What sort of stuff 
would like to see?


As-is, the firmware cannot support more than one Panda Display per host 
machine.  The means of doing this seems rather tricky.  I suppose a pair 
of daisy chain ports can be added to the board design.


Also, the interfacing work is with the klh10 emulator, not SIMh, because 
the former already has hooks for running blinkenlights.


--
David Griffith
d...@661.org

Re: Sun 4/260

2016-03-12 Thread Mike Ross

On Sun, Mar 13, 2016 at 1:45 AM, Roland Schregle
 wrote:
> Hi James,
>
> FWIW, I have slightly more recent Sun 4/330 (SparcServer 330) in my basement 
> in Germany looking for a new home. Not familiar with the 260 and how they 
> differ tho.

Oh... that's one of the last VME machines?

I'm hopefully going to need one of those at some point as a front-end
for my Connection Machine... Germany to NZ is quite a haul though!

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

A gold mine for anybody in Austin...

2016-03-12 Thread Vintage Perfect

Unfortunately, I'm nowhere near Austin! But here is a great gold mine for
somebody local http://austin.craigslist.org/sys/5436553322.html

RE: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Dave Wade

Copied back to the main list….
 
OK on the L66 machines I worked on we always kept the doors closed, there was 
an application, can’t remember its name, we ran on a VDU by the system console 
that displayed the Job Queues, State of Active Jobs, CPU utilization etc. There 
was also a MIPS meter on the console. They were very modular, and as the store 
was in the SCU’s on a multi-cpu system you also needed cross coupled cache 
cables to invalidate the CPU cache when the other CPU overwrote a word in main 
sore that it also had cached.
 
Interleave was also interesting, so you could configure interleave memory word 
by word so alternate accesses went to the “other” SCU. A guy we had in at NERC 
Bidston (was www.pol.ac.uk  ), Vince Martin I think his 
name was who had worked in the Honeywell performance labs, I believe in 
Scottsville. Arizona said this would give much better performance. He also said 
the big bottle neck on the L66 was memory bandwidth. With the fast 6250 BPI 
tapes he said the tape drives could drive the memory flat out, locking the CPU 
out….
 
Dave
 
From: Charles Anthony [mailto:charles.unix@gmail.com] 
Sent: 12 March 2016 15:27
To: Dave G4UGM 
Cc: Ed Sharpe ; j...@jwsss.com; space...@gmail.com; 
jwsm...@jwsss.com; General Discussion: On-Topic and Off-Topic Posts 
; Kevin Monceaux ; 
heal...@aracnet.com; couryhouse.sm...@gmail.com
Subject: Re: Honneywell multics? from panels. the inline phots in this message 
folks -smecc
 
 
 
On Sat, Mar 12, 2016 at 6:44 AM, Dave G4UGM  > wrote:
The panels would be pretty much un-used Unlike 360 panels these were hidden 
behind doors for most of the time. Assuming the work the same on a Multics box 
as on a regular L66/DPS box the only time they were really used was if you 
split a 2 x CPU system into 2 x 1 CPU system, or changed the memory 
configuration from interleaved to non-interleaved. Pretty sure you could IPL 
from the console.
 
 
[My understanding; I wasn't there]
 
The display panels changed over time; later models had a minicomputer with 
management software instead of the big panels.
 
Early models:
 
The CPU cabinet had two doors, with the panels on the inside of the door, so 
that opening the door swung the panel out. (There were probably additional 
panels exposed, but I'm not sure.)
 
One the panels was the CPU status, showing the contents of the registers (A, Q, 
PPR, TSR, Xn, PARn), the major CPU states (fetch, execute, interrupt, fault), 
and major status bits (Append Unit, Operation Unit, Decimal Unit).
 
I understand it was common practice to leave that door open for it visual 
appeal and highly visible 'things are running' status (including the 'idle 
crawl' a distinctive pattern display when Multics was idle.
 
The panels labeled SCU are System Control Units; they were separate cabinets. 
The SCU's contained the memory and handled all communication between CPUs and 
between CPUs and IO controllers.
 
The panels labeled IOM are Input Output Managers; they connected the SCUs to 
peripheral devices; also sometimes 'IOP' (Input Output Processor).
 
The enormous number of configuration switches is due to the extreme modularity 
of the system. Core memory was in the SCUs, not the CPUs; each SCU could have a 
varying amount of memory, in up to 4 banks of varying sizes. Each bank could 
taken out of service, so defining the addressing of the memory in each SCU was 
complex. Each CPU had to have a matching memory configuration panel so that it 
knew which SCU to talk to access a particular memory location.
 
Each CPU had to be cabled to each SCU.
 
Since the IOMs did DMA, the memory configuration panels are duplicated there as 
well, and each IOM cabled to each SCU.
 
The only display panel I would want to utilize is the CPU status; the other 
panels display information which the emulator does not necessarily have and do 
not have the 'wow' factor.
 
-- Charles

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Charles Anthony

On Sat, Mar 12, 2016 at 10:27 AM, Dave Wade  wrote:

> Copied back to the main list….
>
>
>
> OK on the L66 machines I worked on we always kept the doors closed, there
> was an application, can’t remember its name, we ran on a VDU by the system
> console that displayed the Job Queues, State of Active Jobs, CPU
> utilization etc. There was also a MIPS meter on the console. They were very
> modular, and as the store was in the SCU’s on a multi-cpu system you also
> needed cross coupled cache cables to invalidate the CPU cache when the
> other CPU overwrote a word in main sore that it also had cached.
>
>
>

I think the cross-coupled cache cables post-date the code and documentation
I have; I believe that Multics does a inter-CPU interrupts to do cache
invalidation.

SInce the emulator doesn't implement the WAM cache, cache coherency isn't a
problem, and one of my low priority projects is determining if Multics can
use the knowledge of no-caching to to reduce overhead. (Ie. don't signal
invalid cache.)



> Interleave was also interesting, so you could configure interleave memory
> word by word so alternate accesses went to the “other” SCU. A guy we had in
> at NERC Bidston (was www.pol.ac.uk), Vince Martin I think his name was
> who had worked in the Honeywell performance labs, I believe in Scottsville.
> Arizona said this would give much better performance. He also said the big
> bottle neck on the L66 was memory bandwidth. With the fast 6250 BPI tapes
> he said the tape drives could drive the memory flat out, locking the CPU
> out….
>
>
I believe that.

-- Charles

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Charles Anthony

On Sat, Mar 12, 2016 at 12:32 PM, Noel Chiappa 
wrote:

>  > From: Charles Anthony
>
> > The enormous number of configuration switches is due to the extreme
> > modularity of the system. ... Each bank could taken out of service
>
> The really amazing thing (considering the vintage) was that that
> reconfiguration could be done with the power on, and the system running!
>
> E.g. MIT had a two-CPU three-memory system; at night, they used (while the
> system was running!) to take off one of the CPUs and a memory box, bring
> them
> up as a separate development system, and in the morning, add the 'borrowed'
> CPU and memory back onto the main system - without ever shutting the main
> system down! People using it at the time could't even tell it had
> undergone a
> mitosis, and then a merge.
>
>
The ISOLTS (Isolated Testing Subsystem) performs CPU diagnostics on
multi-CPU systems.

It dynamically reconfigures Multics to take the one of the CPUs offline and
to reserve a bank of memory in one the SCUs (the memory is still visible to
Multics, but reserved for ISOLTs use). The offline CPU is hung at a 'Delay
until interrupt' instruction. The memory configuration switches are then
set on the offline CPU so that the reserved block of memory appears to that
CPU as a 128K block of memory starting at location 0. ISOSLTS when installs
a bootstrap loader in the reserved memory block, with an entry at the
interrupt handler vector.

ISOLTS sends an interrupt to the offline CPU, the interrupt vector
transfers to the bootstrap loader, which sets a flag in memory indicating
that all of that reconfiguration was done correctly. ISOLTS sees the flag
set, and then starts loading tests into memory and running them by setting
the interrupt vector and interrupting the CPU, and watching memory to see
the test results.

When the tests are done, the CPU configuration switches are set back, the
SCU memory is released, and Multics brings the CPU back online.

I get bloody impressed just watching it on the emulator; doing it in a
production environment must have been spectacular.

-- Charles

Noel
>

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Noel Chiappa

 > From: Charles Anthony

> The enormous number of configuration switches is due to the extreme
> modularity of the system. ... Each bank could taken out of service

The really amazing thing (considering the vintage) was that that
reconfiguration could be done with the power on, and the system running!

E.g. MIT had a two-CPU three-memory system; at night, they used (while the
system was running!) to take off one of the CPUs and a memory box, bring them
up as a separate development system, and in the morning, add the 'borrowed'
CPU and memory back onto the main system - without ever shutting the main
system down! People using it at the time could't even tell it had undergone a
mitosis, and then a merge.

Noel

Re: VMS 4.4 source code microfiche

2016-03-12 Thread Al Kossow




On 3/12/16 8:11 AM, Antonio Carlini wrote:


It's probably worth experimenting a little


No, it's not.
I'm sorry, but file size matters squat compared to the time it's
going to take to scan them.

Re: VMS 4.4 source code microfiche

2016-03-12 Thread Antonio Carlini


On 12/03/16 16:04, j...@cimmeri.com wrote:


Can that scanner produce anything other than massive .png files?



I wonder whether it can do B G4 encoded at something like 600dpi. That 
should
cut the size down a bit and produce something that perhaps could then be 
OCRd.


My recollection is that each page of fiche is something like 13x30 
panels, so 300-400
images. At current size that would be 1GiB-ish per sheet of fiche. A 
release must be in
the region of 400 sheets or more (I'm guessing, I've not counted mine 
...) so 0.5TiB

per release.

It's probably worth experimenting a little, assuming the scanner has 
suitable knobs that

can be twiddled...

Antonio

--
Antonio Carlini
arcarl...@iee.org

Re: VMS 4.4 source code microfiche

2016-03-12 Thread j...@cimmeri.com



Can that scanner produce anything other 
than massive .png files?


- J.

On 3/11/2016 9:12 PM, devin davison wrote:

Well, I have the scanner and the time, I am going to put in online anyways.
It may not be the full source, but perhaps it will come in handy for
someone else.
  I only spent a few minutes scanning those 12 pages. It was a just a quick
initial run of the scanner to learn how to operate it and save the images.
Once i get it all scanned, I will post a link to it.

--Devin

On Fri, Mar 1

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Charles Anthony

On Sat, Mar 12, 2016 at 6:44 AM, Dave G4UGM  wrote:

> The panels would be pretty much un-used Unlike 360 panels these were
> hidden behind doors for most of the time. Assuming the work the same on a
> Multics box as on a regular L66/DPS box the only time they were really used
> was if you split a 2 x CPU system into 2 x 1 CPU system, or changed the
> memory configuration from interleaved to non-interleaved. Pretty sure you
> could IPL from the console.
>
>
>

[My understanding; I wasn't there]

The display panels changed over time; later models had a minicomputer with
management software instead of the big panels.

Early models:

The CPU cabinet had two doors, with the panels on the inside of the door,
so that opening the door swung the panel out. (There were probably
additional panels exposed, but I'm not sure.)

One the panels was the CPU status, showing the contents of the registers
(A, Q, PPR, TSR, Xn, PARn), the major CPU states (fetch, execute,
interrupt, fault), and major status bits (Append Unit, Operation Unit,
Decimal Unit).

I understand it was common practice to leave that door open for it visual
appeal and highly visible 'things are running' status (including the 'idle
crawl' a distinctive pattern display when Multics was idle.

The panels labeled SCU are System Control Units; they were separate
cabinets. The SCU's contained the memory and handled all communication
between CPUs and between CPUs and IO controllers.

The panels labeled IOM are Input Output Managers; they connected the SCUs
to peripheral devices; also sometimes 'IOP' (Input Output Processor).

The enormous number of configuration switches is due to the extreme
modularity of the system. Core memory was in the SCUs, not the CPUs; each
SCU could have a varying amount of memory, in up to 4 banks of varying
sizes. Each bank could taken out of service, so defining the addressing of
the memory in each SCU was complex. Each CPU had to have a
matching memory configuration panel so that it knew which SCU to talk to
access a particular memory location.

Each CPU had to be cabled to each SCU.

Since the IOMs did DMA, the memory configuration panels are duplicated
there as well, and each IOM cabled to each SCU.

The only display panel I would want to utilize is the CPU status; the other
panels display information which the emulator does not necessarily have and
do not have the 'wow' factor.

-- Charles

RE: Honneywell multics? from panels. the inline phots in this message folks -smecc

2016-03-12 Thread Dave G4UGM

The panels would be pretty much un-used Unlike 360 panels these were hidden
behind doors for most of the time. Assuming the work the same on a Multics
box as on a regular L66/DPS box the only time they were really used was if
you split a 2 x CPU system into 2 x 1 CPU system, or changed the memory
configuration from interleaved to non-interleaved. Pretty sure you could IPL
from the console.

 

Dave

 

From: couryho...@aol.com [mailto:couryho...@aol.com] 
Sent: 12 March 2016 11:53
To: j...@jwsss.com
Cc: space...@gmail.com; dave.g4...@gmail.com; charles.unix@gmail.com;
jwsm...@jwsss.com; cctalk@classiccmp.org; ke...@rawfeddogs.net;
heal...@aracnet.com; couryho...@aol.com; couryhouse.sm...@gmail.com
Subject: Honneywell multics? from panels. the inline phots in this message
folks -smecc

 

ok sent to  all the people cc on the multics stuff..  will not  go though on
main listserv probably

here are some of the panels  think there is more  there are at least  2 of
each  type

one set will make display her  at  smecc museum in az  the other set???
maybe someone want to wire into an emulator <<>>   

aside  from a little  dust and bad  lighting these things  look   like they
were  pretty unused   thanks  ed#  www.smecc.org

Re: VMS/RSTS/RSX manuals available, SOC, DECdirect books, Newmarket UK

2016-03-12 Thread Jerome H. Fine


>Adrian Graham wrote:


On 11/03/2016 17:54, "Paul Koning"  wrote:



They're in a sales office and I forgot about them when you visited otherwise
you could've taken them. I'm guessing at the versions but it'll probably be
VMS 5.5 and RSTS4 but I can check on Monday.
 


RSTS V4 (from 1973) is from the white binder era.  Then came blue, then gray,
then "chinese red" if I remember the order correctly.  Maybe the last two are
swapped.  So gray would suggest a fairly late version, perhaps V8 or so.
Still definitely interesting and potentially worth scanning; bitsavers only
has a few versions and the differences can be significant.


OK, they're definitely grey and the RSX ones are Orange. When I'm out and
about later today I need to drive past work so I'll call in and
check/photograph.


Just to add to the color choices that DEC made, as far as I can remember,
for RT-11 the manuals were blue at one point, then orange and finally grey.

In addition, the size of each binder used to vary quite a bit and there were
relatively few binders, although the total size of the material tended 
to remain

the same.  But at the very last when the grey manuals arrived with V05.05 of
RT-11, the size of all binders was the same and the various manuals were
redistributed when that was needed so that big binders were broken up.
In the case of a very large single manual in a very large binder, the manual
was also split into two and two binders.

Finally, the TECO manual was omitted entirely after about V05.03 of RT-11.
I can't remember when.

Jerome Fine

Re: Which RT-11 for an 11/03

2016-03-12 Thread Richard Cini

Jerome —

Thanks for jumping in here. All good questions, and here’s what my plan 
is.

I bought the H11 as a project. I have a soft spot for the PDP-11, after 
owning (and donating) an 11/34 to the RICM. This unit needed a lot of physical 
TLC but was believed to be functional (it was). 

The original configuration was the CPU card (DEC), two 16kw memory 
boards (Heath; with appropriate memory hole at the top) and a single SLU 
(Heath). I located two more SLUs (all Heath), an extra memory board (32kw; 
unbranded) and a parallel board (Heath; not installed).

After lots of cleaning, then qualifying the power supply, and 
confirming the board jumpers were set properly, I fired it up, using PDP11GUI 
as the console, and I got the ODT prompt. So, good news there.

My unit did not come with Heath’s RX01-equivalent (and no software or 
manuals), so there’s no method of storage. I stumbled upon the TU58EM program 
and since I had two SLUs configured properly, I thought I’d give it a try as an 
alternative to nothing. I really don’t have the room for a real RX01, so I 
though this was a fair compromise.

What am I going to do with this setup? I don’t know. Right now it’s fun 
reacquainting myself with DEC after about 10 years without one.


Rich

--
Rich Cini
http://www.classiccmp.org/cini
http://www.classiccmp.org/altair32







On 3/11/16, 9:21 PM, "cctalk on behalf of Jerome H. Fine" 
 wrote:

> >On Thursday, February 10th, 2016 at 12:51:30 - 0500, Richard Cini wrote:
>
>>Is there a listing somewhere of what versions of RT-11 work with which CPUs? 
>>The Heath H11 uses the LSI-11 which I think is an 11/03 equivalent. Is there 
>>a specific version (or maximum version) designed for this CPU?
>>
>>I tried v4 using a method I found on-line (modifying with SIMH to make it 
>>bootable as a TU58 image rather than an RK) but it doesn't work so I wanted 
>>to first eliminate the system version as the potential problem.
>>
>Sorry for the delay in my answer.  I was out of town for the last
>36 hours, so I just noticed this thread.
>
>For maximum flexibility, I would suggest V05.03 of RT-11.  It is
>just about the most widely available and has the benefit of probably
>being completely legal to use on a non-commercial basis with SimH.
>
>V04.00 of RT-11 will probably run equally well, but obviously
>without some of the many additional features found in V05.03
>of RT-11.  In addition, you might want to check even later
>versions of RT-11, all of which still run on a PDP-11/03 CPU.
>
>Under V05.03 of RT-11, you can use either distributed
>Unmapped Monitor, RT11SJ or RT11FB.  The size will be
>larger than from V04.00 of RT-11, but I suggest that the
>additional features are more than worth while.  Since you
>have all 32 KW or memory or 64 KB, you will not have
>any problem booting RT-11.
>
>If you have any specific questions using Ersatz-11 with
>a PDP-11/03, just ask.  That will make sure that the
>configuration and the boot device is set up correctly.
>
>Just for practice, you might try using Ersatz-11 with V05.03
>of RT-11 with SET  CPU 03.  You will find that Ersatz-11
>is trivial to use and that it supports emulation of all types of
>disk drives including TU-58, RK05, RL02 and SCSI, named,
>respectively, DD:, RK:, DL: and DU:, the same as DEC names
>them.  Be warned that after you practice with Ersatz-11, you
>may find that an LSI-11, also called a PDP-11/03, is a bit
>slower than running with Ersatz-11, even on a 486.  My
>experience with just a 750 MHz Pentium III is that RT-11
>runs about 15 times as fast as a PDP-11/93.  On a current
>I7 from Intel, I expect speeds more than 100 times as fast
>as a PDP-11/93.
>
>If you provide some of the information requested below, a
>version of RT-11 might be suggested which is a better fit.
>Otherwise, my assumption at present is that you want to
>use RT-11 since it is the only reasonable choice out of
>RT-11, RSX-11 and RSTS/E, although I am reasonably
>sure that RSTS/E can't run on a PDP-11/03.  Further, you
>want to run RT-11 to be able to show that you can run
>RT-11 on the PDP-11/03 hardware that you have.  That
>is quite different from the original reason a PDP-11/03
>system was purchased, namely to run specific application
>programs which were able to run under RT-11.  If I
>am incorrect, please let me know and advise otherwise.
>
>It does sound like you have the Heath Kit version of the hardware.
>If so, then you probably don't have a hard disk drive.  A complete
>list of the actual hardware will be helpful.  In addition, even more
>important from my point of view is why you want to use the hardware
>that you have to run RT-11 (most likely because it will not run anything
>else very easily) and then which specific application programs will be
>run after you are successful in getting RT-11 to run.  Just as important
>is how you will interface with the

Re: OT: lenses (Was: Front Panels - PDP8 and PDP 11

2016-03-12 Thread Marco Gariboldi

2016-03-12 0:06 GMT+01:00 Roland Schregle :

>
> Have the Tessar on a 3.5B (aka MX-EVS). Excellent expect when wide open as
> mentioned here, though I wouldn't call it entry level. I think Zeiss made
> an earlier, sub-standard lens (Biotar ?) for Rollei before they could
> deliver 75mm Tessars.
>

Biotar sub-standard?  Germans happily used them on their film cameras,
rather extensively during WW II.  I think you might be thinking of the Jena
(GDR) Biometar instead, which later became known as Pentacon.



> Somebody mentioned the Zeiss ZM line for Leica. Have the f/2.8 35mm Biogon
> and the f/2 50mm Planar for my M3 and M2. These perform very close to the
> original Leitz glass, but are at least affordable for mere mortals.


Indeed and, more importantly, I'm very happy with my Biogon.  Plus, that
blue orb also looks nice.


 - MG

Re: Sun 4/260

2016-03-12 Thread Mattis Lind

2016-03-12 9:56 GMT+01:00 James Vess :

> Howdy there folks,
>
> I've been kicking myself for giving away a dying Sun4/260 due to space
> issues and moving about 15 years ago and since then my life has settled
> I've started looking occasionally to see if I can find another one.
>
> Has anyone seen any of these units in a workable condition that are for
> sale or possibly even loan?
>

There is someone in the UK that sells a lot of parts from a 4/2xx machine:

http://www.ebay.co.uk/itm/161997957466

/Mattis


>
> I never got a good chance to dig into the one I had and I regret it, just
> looking to recoup lost time :)
>
> Thanks,
> James
>

Re: Any word on the Multics revival front?

2016-03-12 Thread jwsmobile




On 3/11/2016 11:45 PM, couryho...@aol.com wrote:

I have front panels  for  Honeywell huge  black and  white   with tons of
tiny switches and leds.
  
kind of like   these

http://www.glennsmuseum.com/components/pics/multics_panel_cu2.jpg
  
http://www.glennsmuseum.com/components/pics/multics_panel_cu1.jpg
  
some have more white areas   is from a   6000?  dps8? 8000?
  

It looks a lot like one in the collection which contained the one I have.

This has my panel, as well as ones from when it was listed on Ebay. The 
black panel looks like it might be similar to the one you are referring to.


http://jimsoldtoys.blogspot.com/2016/03/honeywell-6180-system-maintenance-panel.html

thanks
Jim

Re: OT: lenses (Was: Front Panels - PDP8 and PDP 11

2016-03-12 Thread Roland Schregle

On 11/03/2016, at 8:01 AM, Zane Healy  wrote:

> 
>> On Mar 10, 2016, at 10:05 PM, couryho...@aol.com wrote:
>> 
>> I  wonder if the tele tessar was a true  tessar   design  or  just a  use 
>> of  'the name' ? I have seen   snipits in google referring to it being a 
>> true 
>> telephoto...  with a true  tessar formula  lens  IS NOT.
> 
> I think it’s based on the Tessar, but is something different from what’s in 
> the Hasselblad manual.  The cross-section is definitely different.  There are 
> apparently at least two Tele-Tessar designs, with different numbers of 
> elements.
> 
>> ok  the  norm   for the hassleblad was a80 mm  f  2.8 planar...
>> 
>> in the rolliflex   the tessar was the entry level lens... the  planar  the  
>> upgrade.
>> 
>> my  first  'real' camera was a 1933 rolliflex  with a   f3.5 tessar.   not 
>> bad  at  all  but a little soft  wide open.
>> I still have  this  camera. and the low  shutter   speeds are a little  
>> slow  but OTW   rest is   fine..
>> In  HD  I  bought an argus  c3   from my  geometry teacher  for   $8   and 
>> used it a lot   more  shots  per  roll and  would operate  eye level  and 
>> had a  pretty  good  split image rangefinder.. the   lens  was  decent too.
>> 
>> when I  went in USAF  sold   the  C#  to  my  brother but  kept the 
>> rolliflex  (  wish I had   saved both! as  the argus  shot  some of  my   
>> first  
>> press  work)  adn  when in USAF   got a  SLR.
> 
> I’ve not been able to justify the cost of a Planar Rolleiflex, though I’d 
> really love one with a nice f/2.8 Planar lens.  Both of mine have the 75mm 
> f/3.5 Tessar.  The older of my two is from 1936, the newer from about 1958.  
> For me the Rollei is more of a small lightweight travel camera, or shooting 
> for fun, than a serious camera.  Sort of a “getting back to my roots” sort of 
> thing, as I started with a Yashica 44LM TLR.

There's always the Schneider Xenotar as alternative to the Planar; got one on 
my 2.8C. The performance is pretty much identical for a fraction of the price. 
Of course it doesn't have the same prestige. There's been endless discussions 
about the relative merits of these two lens, but for all intents and purposes, 
they are absolutely on par. They're for users, not collectors.

Have the Tessar on a 3.5B (aka MX-EVS). Excellent expect when wide open as 
mentioned here, though I wouldn't call it entry level. I think Zeiss made an 
earlier, sub-standard lens (Biotar ?) for Rollei before they could deliver 75mm 
Tessars.

Also have Distagon wide angles for my SL35 (Rollei's 1st foray into 35mm SLRs), 
including a clunky f/1.4 35mm and an f/2.8 25mm. These are superb lens; even 
the ones made under license by Rollei Singapore are pretty good. The Zeiss ones 
are more solidly built tho. Of course I also have the Planar as standard lens 
for the SL35, plus a 200mm TeleTessar. The latter is fairly unimpressive unless 
really stopped down.

Somebody mentioned the Zeiss ZM line for Leica. Have the f/2.8 35mm Biogon and 
the f/2 50mm Planar for my M3 and M2. These perform very close to the original 
Leitz glass, but are at least affordable for mere mortals. Having said that, I 
find the colour rendition of these lens over the top; way too saturated 
compared to the earlier Zeiss lens (note that these are actually made by Cosina 
in Japan).

--GT

--
"END OF LINE" [MCP, 1982]

Re: today's haul

2016-03-12 Thread Earl Evans

Very nice, congrats! Looking forward to the pictures.

- Earl


On Fri, Mar 11, 2016 at 7:49 PM, Jay West  wrote:

> A system I have always wanted (spent much of my career working on) has
> finally been acquired.
>
>
>
> A Prime (Pr1me) model 2250 aka "rabbit". The cpu chassis is in the
> foreground. I do have the bezels (they were removed for shipping). In the
> background you can see the rebadged cipher F880 in the same type of rack
> that will sit next to it.
>
>
>
> https://www.flickr.com/photos/131070638@N02/25084207344
>
>
>
> I'm told it has two 158mb priams, an ics1, and either 1mb or 2mb ram. Will
> post more pics when I get around to opening it up.
>
>
>
> Best,
>
>
>
> J
>
>
>
>
>
>

Re: Any word on the Multics revival front?

2016-03-12 Thread Eric Smith

On Sat, Mar 12, 2016 at 1:21 AM, Dave Wade  wrote:
[GCOS-8]
> Sadly, I doubt it very much. It was still in use on emulated hardware until 
> relatively recently and I assume BULL was still making money from it and 
> guarding its assets. Thinkage still have GCOS products listed on their web 
> site.

There's at least some possible future upside to that, which is that if
they are (or recently were) still selling and supporting it, then they
probably still actually have it, vs. the huge amount of software of
historical interest that is already lost.  Also, since Group BULL was
willing to make a Multics license available, that may serve as useful
precedent for getting them to offer a similar GCOS license at some
future date when they don't believe it will harm their commercial
interests.

RE: Any word on the Multics revival front?

2016-03-12 Thread Dave Wade



> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Zane Healy
> Sent: 12 March 2016 04:51
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: Any word on the Multics revival front?
> 
> 
> > On Mar 11, 2016, at 6:22 AM, Kevin Monceaux 
> wrote:
> >
> > OI hadn't checked on Multics progress in quite a while.  Yesterday I
> > discovered that the DPS-8/M emulator at:
> >
> >https://SourceForge.net/projects/dps8m/
> >
> > is far enough along to boot Multics.  I thought some folks on this
> > list might be interested in it.
> 
> What I’d like to know is if any copies of GCOS-8 exist in the wild.  That’s 
> what
> I’d personally really like to boot on the emulator.  I used to be able 
> configure
> all the IOP’s, IOM’s, CPU’s, etc. from memory, power them up, and boot
> GCOS-8.
> 
> Zane
> 
Sadly, I doubt it very much. It was still in use on emulated hardware until 
relatively recently and I assume BULL was still making money from it and 
guarding its assets. Thinkage still have GCOS products listed on their web site.

https://www.thinkage.ca/english/gcos/index.shtml

but sadly no longer a "B" compiler. I think that one has slipped past me...

Dave Wade
G4UGM

Re: Which RT-11 for an 11/03

Re: Which RT-11 for an 11/03

Re: Which RT-11 for an 11/03

Re: Which RT-11 for an 11/03

Type 270 disk file on PDP-6

Re: A gold mine for anybody in Austin...

Re: Sun 4/260

Re: Sun 4/260

Introduction and Alpha Micro AM-1200 query

Re: Which RT-11 for an 11/03

Re: Which RT-11 for an 11/03

RE: A gold mine for anybody in Austin...

Re: Honneywell multics? from panels. the inline phots in this message folks...

Re: Sun 4/260

A gold mine for anybody in Austin...

RE: Honneywell multics? from panels. the inline phots in this message folks -smecc

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

Re: VMS 4.4 source code microfiche

Re: VMS 4.4 source code microfiche

Re: VMS 4.4 source code microfiche

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

RE: Honneywell multics? from panels. the inline phots in this message folks -smecc

Re: VMS/RSTS/RSX manuals available, SOC, DECdirect books, Newmarket UK

Re: Which RT-11 for an 11/03

Re: OT: lenses (Was: Front Panels - PDP8 and PDP 11

Re: Sun 4/260

Re: Any word on the Multics revival front?

Re: OT: lenses (Was: Front Panels - PDP8 and PDP 11

Re: today's haul

Re: Any word on the Multics revival front?

RE: Any word on the Multics revival front?

33 matches

Site Navigation

Mail list logo

Footer information