Which RT-11 for an 11/03
Don North
north at alum.mit.edu
Sun Mar 13 00:19:26 CST 2016
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 cctech
mailing list