Which RT-11 for an 11/03
Don North
north at alum.mit.edu
Sun Mar 13 01:23:44 CST 2016
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, &ctlr->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: 00000200
>> DBG(930594)> TDC DAT: 0000A0 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... at ...
>> 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
>>> 0000000 240 000 040 001 006 000 000 000 012 000 000 000 000 000 000 000
>>> 0000020 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
>>> 0000040 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
>>> 0000060 000 000 000 000 000 000 000 000 002 012 002 000 000 000 000 000
>>> 0000100 000 002 010 000 306 025 000 140 005 000 303 025 060 000 302 025
>>> 0000120 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:
>>>
>>> +0000: 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 Beta git 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 <mattislind at gmail.com> 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 Beta git 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 .SYS 27P 20-Dec-85 STARTS.COM 1P 20-Dec-85
>>>>>>> DIR .SAV 19P 20-Dec-85 DUP .SAV 47P 20-Dec-85
>>>>>>> DU .SYS 8P 20-Dec-85 RT11SJ.SYS 79P 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 Beta git 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: 000000 (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.SYS 79P 20-Dec-85 SWAP .SYS 27P 20-Dec-85
>>>>>>> STARTS.COM 1P 20-Dec-85 DIR .SAV 19P 20-Dec-85
>>>>>>> RESORC.SAV 25P 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
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
More information about the cctalk
mailing list