10 Mar
2016
10 Mar
'16
2:46 p.m.
There is no difference in the LSI-11 board on an H-11 and a pdp-11/03. What DEC did do
was cripple Heath's version of RT-11 (called HT-11). It would only work with
Heath's H-27 floppy drive unit. The Heath serial, parallel, and memory cards were all
compatible with DEC's offerings, AFAIK.
That being said, I personally don't have experience with true RT-11 on the H-11.
-------- Original message --------
From: Richard Cini
Date:03/10/2016 4:09 PM (GMT-05:00)
To: "General Discussion: On-Topic and Off-Topic Posts"
Subject: Re: Which RT-11 for an 11/03
If I have time tonight I'll log the session with "verbose" set on the
TU58EM. Again, I'm trying the trick of booting from a TU58 emulator and an RK image
with DD as the boot target (supposedly can work but maybe slow). I can see the blocks
being read in but it stops and doesn't give me the sign-on banner.
Rich
Sent from my iPhone
10 Mar
10 Mar
2:51 p.m.
Thanks Gary. This is my understanding as well since everything works with XXDP right from
DEC and I'm not using the H-27. So, I remain optimistic that I can get this working.
Rich
Sent from my iPhone
On Mar 10, 2016, at 5:46 PM, Gary L. Messick <Gary
at realtimecomp.com> wrote:
There is no difference in the LSI-11 board on an H-11 and a pdp-11/03. What DEC did do
was cripple Heath's version of RT-11 (called HT-11). It would only work with
Heath's H-27 floppy drive unit. The Heath serial, parallel, and memory cards were all
compatible with DEC's offerings, AFAIK.
That being said, I personally don't have experience with true RT-11 on the H-11.
-------- Original message --------
From: Richard Cini
Date:03/10/2016 4:09 PM (GMT-05:00)
To: "General Discussion: On-Topic and Off-Topic Posts"
Subject: Re: Which RT-11 for an 11/03
If I have time tonight I'll log the session with "verbose" set on the
TU58EM. Again, I'm trying the trick of booting from a TU58 emulator and an RK image
with DD as the boot target (supposedly can work but maybe slow). I can see the blocks
being read in but it stops and doesn't give me the sign-on banner.
Rich
Sent from my iPhone
5:24 p.m.
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.
Thanks all!
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.classiccmp.org/cini
http://www.classiccmp.org/altair32
On 3/10/16, 5:51 PM, "cctalk on behalf of Richard Cini" <cctalk-bounces at
classiccmp.org on behalf of rich.cini at verizon.net> wrote:
Thanks Gary. This is my understanding as well since everything works with XXDP right from
DEC and I'm not using the H-27. So, I remain optimistic that I can get this working.
Rich
Sent from my iPhone
On Mar 10, 2016, at 5:46 PM, Gary L. Messick <Gary at realtimecomp.com> wrote:
There is no difference in the LSI-11 board on an H-11 and a pdp-11/03. What DEC did do
was cripple Heath's version of RT-11 (called HT-11). It would only work with
Heath's H-27 floppy drive unit. The Heath serial, parallel, and memory cards were all
compatible with DEC's offerings, AFAIK.
That being said, I personally don't have experience with true RT-11 on the H-11.
-------- Original message --------
From: Richard Cini
Date:03/10/2016 4:09 PM (GMT-05:00)
To: "General Discussion: On-Topic and Off-Topic Posts"
Subject: Re: Which RT-11 for an 11/03
If I have time tonight I'll log the session with "verbose" set on the
TU58EM. Again, I'm trying the trick of booting from a TU58 emulator and an RK image
with DD as the boot target (supposedly can work but maybe slow). I can see the blocks
being read in but it stops and doesn't give me the sign-on banner.
Rich
Sent from my iPhone
5:29 p.m.
Again, I don't really have much experience with RT-11. Is it possible the disk image
has drivers for the disk system (which you don't have) and is crashing? Jerome Fine
is the expert on RT-11.
Jerome? Any ideas?
Gary
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Richard
Cini
Sent: Thursday, March 10, 2016 8:25 PM
To: CCTalk
Subject: Re: Which RT-11 for an 11/03
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.
Thanks all!
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.classiccmp.org/cini
http://www.classiccmp.org/altair32
5:51 p.m.
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
process.
Don
info: read unit=0 sw=0x00 mod=0x00 blk=0x0085 cnt=0x0132 info: read unit=0
sw=0x00 mod=0x00 blk=0x0086 cnt=0x3CC8
5:57 p.m.
On 3/10/16, 8:51 PM, "cctalk on behalf of Don North" <cctalk-bounces at
classiccmp.org on behalf of north at alum.mit.edu> wrote:
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
process.
Don
Good point, Don. Maybe I?ll re-create the image again and see if that helps. I?m using the
RT11v4 image from the SIMH distribution and it boots just fine (as an RK05 image) under
SIMH.
Rich
6:01 p.m.
On 3/10/2016 8:57 PM, Richard Cini wrote:
Maybe I?ll re-create the image again and see if that
helps. I?m using
the RT11v4 image from the SIMH distribution and it boots just fine (as
an RK05 image) under SIMH. Rich
Try making an RL02 image from the RK05 image in SIMH and booting from
that (in SIMH).
- JS.
6:07 p.m.
On Mar 10, 2016, at 8:51 PM, Don North <north at
alum.mit.edu> wrote:
I was wondering too. But then again, RT11 can do partial sector reads (and even writes).
They go straight from application through the kernel to the driver. (A partial block
write requires the device, or the driver, to zero-fill to the end of the block -- and yes,
some applications require that and will break if it isn't done right, as I found out
debugging the RC11 driver.)
If memory serves, what you have is part 1 of the boot (1 sector, block 0), part 2 (2
sectors, block 2), then something is looking through the directory (sectors 6 and up) and
then the read from block 134 is presumably a file being read (perhaps a program) and the
stuff at 85 and 86 is ???
It might be informative to dump the directory from the tape and analyze it to see what
files those later reads refer to.
paul
...
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 process.
6:36 p.m.
On 3/10/16, 9:07 PM, "cctalk on behalf of Paul Koning" <cctalk-bounces at
classiccmp.org on behalf of paulkoning at comcast.net> wrote:
If memory serves, what you have is part 1
of the boot (1 sector, block 0), part 2 (2 sectors, block 2), then something is looking
through the directory (sectors 6 and up) and then the read from block 134 is presumably a
file being read (perhaps a program) and the stuff at 85 and 86 is ???
It might be informative to dump the directory from the tape and analyze it to see what
files those later reads refer to.
Paul
Paul ? the image is from the SIMH RT-11 V4.00 software set. There?s something like 150
files on the disk.
Separately?
John ? the SLUs are at what I think are the standard addresses and vectors (per the
Heathkit and DLV11-J manuals) and the ODT and TU58EM work. I don?t know what RT-11 is
looking for but the console @ 177560/60 and TU58 @ 176500/300 (Channel 3 and Channel 0 in
DLV11-J parlance).
I have not tried booting SIMH with the TU58 image (not sure how to do that; need to work
on it).
Regarding getting a real RX01 or RL02, the issue for me is space. It?s pretty convenient
using a laptop and TU58EM (providing I can get something other than XXDPD2D to work). If
someone has already built bootable TU58 RT-11 images, I haven?t found them yet.
Rich
--
Rich Cini
http://www.classiccmp.org/cini
http://www.classiccmp.org/altair32
7:02 p.m.
On 3/10/2016 9:36 PM, Richard Cini wrote:
Separately? John ? the SLUs are at what I think are
the standard
addresses and vectors (per the Heathkit and DLV11-J manuals) and the
ODT and TU58EM work. I don?t know what RT-11 is looking for but the
console @ 177560/60 and TU58 @ 176500/300 (Channel 3 and Channel 0 in
DLV11-J parlance). I have not tried booting SIMH with the TU58 image
(not sure how to do that; need to work on it). Regarding getting a
real RX01 or RL02, the issue for me is space. It?s pretty convenient
using a laptop and TU58EM (providing I can get something other than
XXDPD2D to work). If someone has already built bootable TU58 RT-11
images, I haven?t found them yet.
I have doubts that taking an RK05 image, and copying the DD: bootstrap
in like that, and then simply taking that modified RK05 image and
attempting to boot it as a TU58... I'm not sure if that could work.
Just seems like there'd been some structural differences. But I could
be wrong.
I forget if either SIMH or Ersatz emulates a TU58.. but if they do, try
making an empty tape container (I think TU58EM can do this) and then
build up and RT11 system as outlined in the manual using one of the
emulators. Make sure it can boot in the emulator (if that's possible).
Do you know for sure if a real TU58 can even run RT-11? Never tried it.
p.s. you could also get yourself a qbus SCSI card, and have a much
smaller disk subsystem.
- J.
8:09 p.m.
On 3/10/2016 7:02 PM, js at cimmeri.com wrote:
On 3/10/2016 9:36 PM, Richard Cini wrote:
Creating/running an RT-11 image on a TU58 tape, and then booting/running it
under TU58EM has been
discussed in the past. I would suggest reading thru this thread, as it did
succeed in building a bootable
TU58 RT-11 image:
http://www.vcfed.org/forum/showthread.php?39372-Wanted-RT-11-OS-as-a-TU-58-…
RT-11 can run from a TU58 disk (tape) as demonstrated above, on real PDP-11
hardware.
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.
Theoretically one could attach the emulated serial port in SIMH to a real serial
port that TU58EM is connected to
(or use something like comOcom on windows to wire together virtual serial ports)
and run TU58EM with SIMH,
but I know of noone doing this (I never have, altho I believe it is technically
possible to do).
I believe that ERSATZ-11 has integrated support for TU58 image support mounting,
so that might be the way
to go to build a TU58 image under simulation.
I have seen rumblings that someone might be working on a virtual TU58 device for
SIMH, but maybe it is just
an idea at this point for a rainy day. The code would be pretty straightforward
I suspect.
Don
Separately? John ? the SLUs are at what I think
are the standard addresses
and vectors (per the Heathkit and DLV11-J manuals) and the ODT and TU58EM
work. I don?t know what RT-11 is looking for but the console @ 177560/60 and
TU58 @ 176500/300 (Channel 3 and Channel 0 in DLV11-J parlance). I have not
tried booting SIMH with the TU58 image (not sure how to do that; need to work
on it). Regarding getting a real RX01 or RL02, the issue for me is space.
It?s pretty convenient using a laptop and TU58EM (providing I can get
something other than XXDPD2D to work). If someone has already built bootable
TU58 RT-11 images, I haven?t found them yet.
I have doubts that taking an RK05 image, and copying the DD: bootstrap in like
that, and then simply taking that modified RK05 image and attempting to boot
it as a TU58... I'm not sure if that could work. Just seems like there'd been
some structural differences. But I could be wrong.
I forget if either SIMH or Ersatz emulates a TU58.. but if they do, try making
an empty tape container (I think TU58EM can do this) and then build up and
RT11 system as outlined in the manual using one of the emulators. Make sure
it can boot in the emulator (if that's possible).
Do you know for sure if a real TU58 can even run RT-11? Never tried it.
p.s. you could also get yourself a qbus SCSI card, and have a much smaller
disk subsystem.
- J.
11 Mar
11 Mar
3:09 a.m.
Thanks Don. I did read that thread previously but I will do so again in case I missed a
finer point in it.
Rich
Sent from my iPhone
On Mar 10, 2016, at 11:09 PM, Don North <north at
alum.mit.edu> wrote:
On 3/10/2016 7:02 PM, js at cimmeri.com wrote:
Creating/running an RT-11 image on a TU58 tape, and then booting/running it under TU58EM
has been
discussed in the past. I would suggest reading thru this thread, as it did succeed in
building a bootable
TU58 RT-11 image:
http://www.vcfed.org/forum/showthread.php?39372-Wanted-RT-11-OS-as-a-TU-58-…
RT-11 can run from a TU58 disk (tape) as demonstrated above, on real PDP-11 hardware.
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.
Theoretically one could attach the emulated serial port in SIMH to a real serial port
that TU58EM is connected to
(or use something like comOcom on windows to wire together virtual serial ports) and run
TU58EM with SIMH,
but I know of noone doing this (I never have, altho I believe it is technically possible
to do).
I believe that ERSATZ-11 has integrated support for TU58 image support mounting, so that
might be the way
to go to build a TU58 image under simulation.
I have seen rumblings that someone might be working on a virtual TU58 device for SIMH,
but maybe it is just
an idea at this point for a rainy day. The code would be pretty straightforward I
suspect.
Don On 3/10/2016 9:36 PM, Richard Cini wrote:
Separately? John ? the SLUs are at what I think are the standard addresses and vectors
(per the Heathkit and DLV11-J manuals) and the ODT and TU58EM work. I don?t know what
RT-11 is looking for but the console @ 177560/60 and TU58 @ 176500/300 (Channel 3 and
Channel 0 in DLV11-J parlance). I have not tried booting SIMH with the TU58 image (not
sure how to do that; need to work on it). Regarding getting a real RX01 or RL02, the issue
for me is space. It?s pretty convenient using a laptop and TU58EM (providing I can get
something other than XXDPD2D to work). If someone has already built bootable TU58 RT-11
images, I haven?t found them yet.
I have doubts that taking an RK05 image, and copying the DD: bootstrap in like that, and
then simply taking that modified RK05 image and attempting to boot it as a TU58... I'm
not sure if that could work. Just seems like there'd been some structural
differences. But I could be wrong.
I forget if either SIMH or Ersatz emulates a TU58.. but if they do, try making an empty
tape container (I think TU58EM can do this) and then build up and RT11 system as outlined
in the manual using one of the emulators. Make sure it can boot in the emulator (if
that's possible).
Do you know for sure if a real TU58 can even run RT-11? Never tried it.
p.s. you could also get yourself a qbus SCSI card, and have a much smaller disk
subsystem.
- J. 
10:26 a.m.
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
10:35 a.m.
Mattis -- thanks! I'll check this out in detail when I get home tonight and I'll
give it a try.
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
>
11:22 a.m.
Rich,
If you need to disable the LTC interrupt, it's a jumper wire located on the top
(solder side) of the power supply. It originally came as two single pin socket type
things with a wire jumper-ed between them. When I previously asked whether it had two or
three switches on the front, later models moved it to the front panel.
Also, I vaguely remember issues with booting HT-11 with the LTC enabled. I believe you
could re-enabled it after booting, but that would be a ~40 year old memory!
Gary
________________________________________
From: cctalk [cctalk-bounces at classiccmp.org] on behalf of Richard Cini [rich.cini at
verizon.net]
Sent: Friday, March 11, 2016 1:35 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Which RT-11 for an 11/03
Mattis -- thanks! I'll check this out in detail when I get home tonight and I'll
give it a try.
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
>
11:41 a.m.
Gary -- that must be what the other switch is for. I haven't yet unmounted the PS
board to see what the switch was connected to, only having recently gotten the schematic.
I'll make sure the switch is off (I think it may be on).
The schematic has an unlabeled jumper "J" which is shown connected. The related
transistor connects to the BEVENT signal on the backplane so that must be the LTC. Aha!
Rich
Sent from my iPhone
On Mar 11, 2016, at 2:22 PM, Gary L. Messick <Gary
at realtimecomp.com> wrote:
Rich,
If you need to disable the LTC interrupt, it's a jumper wire located on the top
(solder side) of the power supply. It originally came as two single pin socket type
things with a wire jumper-ed between them. When I previously asked whether it had two or
three switches on the front, later models moved it to the front panel.
Also, I vaguely remember issues with booting HT-11 with the LTC enabled. I believe you
could re-enabled it after booting, but that would be a ~40 year old memory!
Gary
________________________________________
From: cctalk [cctalk-bounces at classiccmp.org] on behalf of Richard Cini [rich.cini at
verizon.net]
Sent: Friday, March 11, 2016 1:35 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Which RT-11 for an 11/03
Mattis -- thanks! I'll check this out in detail when I get home tonight and I'll
give it a try.
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
11:19 a.m.
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
>
12 Mar
12 Mar
3:55 p.m.
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
>>
3:58 p.m.
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
>>
9:47 p.m.
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 .dks 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
>>
10:19 p.m.
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
>>
11:14 p.m.
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
>>>
11:23 p.m.
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
>>>>
>
>
13 Mar
13 Mar
4:11 a.m.
2016-03-13 8:23 GMT+01:00 Don North <north at alum.mit.edu>:
Ok, filed as: https://github.com/simh/simh/issues/285
On 3/12/2016 11:14 PM, Don North wrote:
Well done!
Thanks. Myself I never got further than finding that the boot block read in
was not the same as the one on tape. But now it looks obvious it was just
shifted one byte.
/Mattis
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 !
6:44 a.m.
That's an awesome find Don, thanks!
Rich
Sent from my iPhone
On Mar 13, 2016, at 3:23 AM, Don North <north at
alum.mit.edu> wrote:
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;
>
10 Mar
10 Mar
5:59 p.m.
On 3/10/2016 8:24 PM, Richard Cini wrote:
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.
Have you checked your SLU addresses and vectors to be sure they're
standard values (ie. what RT11 is expecting)? I realize XXDP is
running, but just confirm anyway.
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.
Can you then boot the SIMH PDP-11 using that TU58 image?
Not sure where to go from here.
Well, you might really delve in and get yourself a real disk
subsystem... RL02 or RX01.
- JS.
3206
days inactive
3209
days old
25 comments
6 participants
participants (6)
-
Gary＠realtimecomp.com -
js＠cimmeri.com -
mattislind＠gmail.com -
north＠alum.mit.edu -
paulkoning＠comcast.net -
rich.cini＠verizon.net