OK, I have figured out how to modify TSGEN.MAC, use PUTR to make a disk
image, load it in SIMH, reassemble, relink, and *finally* send it to an RL02
pack via vtserver!
TIme-consuming but doable. I've been wrestling with this all day.
BUT - TSX+ 6.50 just will not run. At all.
Using RT-11SJ (5.01), after typing "R TSX" I can hear the disc access for a
few seconds, a pause, a few more accesses... then nothing. It just hangs.
Nothing on the console either., no response to <CR>.
When starting it in SIMH (the same disk image), I get the error message
?TSX-F-Computer line clock is not working. Figured that was just a SIMH
thing.
But the address/vector is correct in TSGEN.MAC... and when checking TIME in
RT-11, the seconds advance in real-time like it should.
On the real hardware, the error message doesn't display, and the clock is
running...
My old version of TSX+ is 6.16 and it runs fine on console and SLU 2, just
needs rebuilt to use different serial cards than the original system.
So where should I start looking first? RT-11 version incompatibility?
Any TSX+ experts online? Thanks for any help. This is driving me nuts!
And even more bizarrely... it crawled its way up to the 7400K block, and now
it's going at normal speed again! 10MB should be done soon.
I have no idea what could be causing this major slowdown from 6.6-7.4 MB.
It's not the drive because two different ones do the same thing (and they
work perfectly otherwise)...
Hopefully I won't have to go through the (edit, reassemble, relink, PUTR
transfer to an image, vtserver to the disk) loop too many times, attempting
to get my DHV11/16D to function with TSX+ 6.50... I had somehow inserted a
couple of characters that didn't belong there while editing (bumped the
keyboard maybe?) so I'm on the second pass.
Also I found what looks like a typo in the TSGEN.MAC file if anyone's
interested.
-----Original Message-----
>But there is some kind of bug that always appears at the same point, in the
>middle of the next 100K block after "6600K written".
>The data transfer stops (no more head motion/ready light flicker on the
>RL02), and the character that vtserver uses to indicate a write operation
>just repeats endlessly and rapidly until I kill it.
More information and a correction: I let it run on, and it is still reading
and writing, but at a much slower and intermittent rate than the first 6.6
MB.
The filler character is just a time marker of some kind, since I can still
see the "r" indicating a read from the .dsk image, and the light on the RL02
flickers after a few of those.
So it's slowed way down, but not stopped! Even more mysterious.
Anyway, this disk has 13800 blocks out of 20800 used. If RT-11 stores data
(including the directory structure) starting from block 0, I may be able to
kill the writes after 7 MB.
(Unfortunately I think I neglected to squeeze the image before sending it to
the RL - and naturally the important TSX files are near the end - which
means I have to wait for most of it).
If I have to do it again, I'll squeeze and then kill it after 7 MB and see
what I got!
>But there is some kind of bug that always appears at the same point, in the
>middle of the next 100K block after "6600K written".
>The data transfer stops (no more head motion/ready light flicker on the
>RL02), and the character that vtserver uses to indicate a write operation
>just repeats endlessly and rapidly until I kill it.
More information and a correction: I let it run on, and it is still reading
and writing, but at a much slower and intermittent rate than the first 6.6
MB.
The filler character is just a time marker of some kind, since I can still
see the "r" indicating a read from the .dsk image, and the light on the RL02
flickers after a few of those.
So it's slowed way down, but not stopped! Even more mysterious.
Anyway, this disk has 13800 blocks out of 20800 used. If RT-11 stores data
(including the directory structure) starting from block 0, I may be able to
kill the writes after 7 MB.
(Unfortunately I think I neglected to squeeze the image before sending it to
the RL - and naturally the important TSX files are near the end - which
means I have to wait for most of it).
If I have to do it again, I'll squeeze and then kill it after 7 MB and see
what I got!
I sometimes use vtserver to download disk images to the RL02's on my
PDP-11/23+. Takes quite a while at 9600 baud, too :)
But there is some kind of bug that always appears at the same point, in the
middle of the next 100K block after "6600K written".
The data transfer stops (no more head motion/ready light flicker on the
RL02), and the character that vtserver uses to indicate a write operation
just repeats endlessly and rapidly until I kill it.
Does anyone else encounter this limitation, and if so, how did you fix it?
Fortunately I haven't wanted to image a disk that's more than 2/3 full so
far... I make sure to squeeze the disk in SIMH before transferring the
image. But it'd be nice to be able to image a full (10 MB) RL02 and not have
to worry about it failing.
Any ideas?
thanks
Charles
Dennis,
It sounds like you are looking for an Ultrix 3.0 standalone boot tape. While I found a number of people who claim to have a physical tape, with some claiming to have imaged the tape, I was unable to find an image on-line. That being said, it?s possible to use the Ultrix 2.0 standalone bootable tape (AQ-JU00C, available from bitsavers.org) with a couple of edits at the end - I did this to get 2.2 up and running.
Since Ultrix 2.0 only supports a limited number VAX processors, the first stage has to be run on one of those processors, I always use microvax2. Subsequent stages may be run on any processor supported by Ultrix 3.0.
Stage 1:
I use the following .ini file:
# Boot from standalone tape. This MUST be performed on a microvax2 instance.
set rl dis
set ts dis
set rq0 ra81
att rq0 system.dsk
att tq0 AQ-JU00C-BE_ULTRIX-32_2.0_SA_87.tap
set tti 7b
set tto 7b
boo
Attach the Ultrix 3.0 supported tape to tq0 when it asks. This stage will create the root partition and restore from the tape. No special handling at this point, just answer the questions as for a normal install.
Stage 2:
Use the VAX simulator for the target system (I used vax780) and boot rq0. After answering some questions it will fail trying to create a file system on /dev/rra0 which doesn?t exist - you need to edit /.minidevice as follows:
# ed .minidevice
22
1
RA81 ra 0 TK50 tms 0
s/0/0g
RA81 ra 0g TK50 tms 0
w
23
q
Reboot the system and it will create a file system on /dev/ra0g, copy the base packages along with any you have selected and build a custom kernel. After all this reboot again and it will drop you into single user mode after complaining about "Can't stat /dev/ra0ga?. Edit /etc/fstab:
# ed /etc/fstab
54
1
/dev/ra0ga:/:rw:1:1:ufs::
s/0g/0
/dev/ra0a:/:rw:1:1:ufs::
w
53
q
Reboot again and you should have a functioning system.
John.
This may be a silly question... but how can I transfer a text file from my
PC into SIMH for PDP-11?
Is it even possible to create a disk or tape image from source code?
Attaching files requires them to be images...
I have significant changes to make to TSGEN.MAC (TSX-Plus definitions file)
and it will be MUCH easier to edit it on my laptop with a screen editor,
than in SIMH (or on the real hardware) using the line editors!
The only method that comes to mind is to start the actual 11/23+, open the
text editor for input, then use a terminal program like Teraterm to "play"
the file as though I were typing it in.
But I don't have the rest of the TSX-Plus source files, linker, etc. so I
would have to transfer them using VTserver anyway...
thoughts?
thanks
Charles
> From: Glen Slick
> when I wanted to assemble some code with the RT-11 assembler but wanted
> to edit the source code elsewhere and then transfer the code into a
> SIMH disk image.
Someone should write the SIMH equivalent of Ersatz-11's 'DOS device' (which
allows the -11 access to the file system on the host - and also the ability
to send arbitrary commands to the emulator).
I find it mind-bogglingly useful for going round the edit-compile loop, while
using a good editor (Epsilon for me) on the host OS. Having written a Unix
driver for the device, I have a sack of Unix commands that use it, e.g. to
retrieve the file foo.c from the host, I just say 'hrd foo.c' to the PDP-11
Unix's shell, and it's there.
Super-painless, and does't add any noticeable amount of time/work to going
around the loop. I don't need to give the full file name since there's also
'hcd <dir>'. To change the switch register contents, 'sc <value>'. Etc, etc.
How all you SIMH users manage without it is beyond me. Luckily I only need
-11 emulation, so I don't have to put up with life without it - and would
refuse to.
If anyone is seriously interested in adding it to SIMH, there's an -11 device
spec available; I strongly suggest using the same spec; then for Unix, at
least, all the -11 code (driver, user commands) is already done.
Noel
Anyone have a copy of the RK611 Technical Manual (EK-RK611-TM-001 is the
version that's attested)? It's not online.
(I have a copy in my fiche set, but my fiche reader died - no, it's not
the bulb, already changed that! :-)
Noel
In one of the repositories of Infocom game source code recently uploaded
to Github, there's an executable that appears to have come from an m68k
Unix machine of some sort. It's at
https://github.com/historicalsource/zork-german/blob/master/zap. Over at
intfiction.org[1], it was initially claimed to be from a Macintosh. Then
I suggested it was from a pre-Sparc Sun machine. Then someone else
suggested it was from A/UX. Does anyone know anything more conclusive? I
based my idea on what I got from running strings(1) on the file.
Copyright (c) 1987 Apple Computer, Inc.,
1985 Adobe Systems Incorporated,
1983-87 AT&T-IS,
1985-87 Motorola Inc.,
1980-87 Sun Microsystems Inc.,
1980-87 The Regents of the University of California,
1985-87 Unisoft Corporation, All Rights Reserved.
[1] https://intfiction.org/t/infocom-source-code-posted/41156/23
--
David Griffith
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?