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