Which RT-11 for an 11/03
north at alum.mit.edu
Thu Mar 10 19:51:45 CST 2016
On 3/10/2016 5:24 PM, Richard Cini wrote:
> Gary, et. al.--
> Ok, I spent some time trying this again, and here’s what I did. The system is very basic — LSI-11 CPU, 32kw of RAM and two SLU cards. Using PDP11GUI and TU58em emulator. XXDPD2D tape image loads and runs properly with this configuration and the standard boot loader.
> Based on the instructions on Malcom Macleod’s site, I prepared an RT-11 TU58-target tape image from the base RK05 image from the SIMH distribution. The key incantation is:
> COPY/BOOT:DD RK0:RT11SJ.SYS RK0:
> What this should do is make the disk image bootable as a TU58 image.
> Next, I fired-up TU58em, loaded the boot loader into the H11 and ran it. Here’s the log from TU58:
> D:\DEC>tu58em -v -p 3 -s 9600 -w rtv4_dd.dsk >>log.txt
> info: unit 0 rw file 'rtv4_dd.dsk'
> info: serial port 3 at 9600 baud
> info: TU58 emulation start
> info: R restart, S toggle send init, V toggle verbose, D toggle debug, Q quit
> info: emulator started
> info: boot unit=0 blk=0x0000 cnt=0x0200
> info: read unit=0 sw=0x00 mod=0x00 blk=0x0002 cnt=0x0800
> info: read unit=0 sw=0x00 mod=0x00 blk=0x0006 cnt=0x0400
> info: read unit=0 sw=0x00 mod=0x00 blk=0x0008 cnt=0x0400
> info: read unit=0 sw=0x00 mod=0x00 blk=0x000A cnt=0x0400
> info: read unit=0 sw=0x00 mod=0x00 blk=0x000C cnt=0x0400
> info: read unit=0 sw=0x00 mod=0x00 blk=0x0134 cnt=0x0A00
> info: read unit=0 sw=0x00 mod=0x00 blk=0x0085 cnt=0x0132 info: read unit=0
> sw=0x00 mod=0x00 blk=0x0086 cnt=0x3CC8 At this point, the RUN LED goes off and the system halts. It looks like the boot loader is loading and running the second-level loader on the tape, but something happens after that. Not sure where to go from here.
These last two read commands look awful suspicious to me. A single logical
device block is 512B (or 0x200) so the count
parameter is 0x200 for one block, 0x400 for two consecutive blocks, etc. 0xA00
is five consecutive blocks.
However, 0x0132 (306. bytes) is a partial block read, and 0x3CC8 (15560.) is a
read of 30.+ blocks. So I would speculate
that the code went south prior to these two read commands. Just a guess of
course as I have never done this particular
task. But I would guess that the image you are using has been corrupted in the
info: read unit=0 sw=0x00 mod=0x00 blk=0x0085 cnt=0x0132 info: read unit=0
sw=0x00 mod=0x00 blk=0x0086 cnt=0x3CC8
More information about the cctalk