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...@...
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 <mattisl...@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
