Alright! I booted up RSX11M 4.2 a little bit ago on my 11/23-plus! I had
logged in to one of my Linux machines from my work laptop to run the copy,
and of course they installed Windows updates and it needed to reboot. But I
have a little more than half of the disk image copied over so I was able to
boot it up. Very exciting! I'll start the copy over a bit later in the week
when I can let it run longer. I also have a DECNA card in the machine now
so I can install DECnet and play with that uner RSX. I wish I could install
TCP/IP but I understand the hardware doesn't have the separate I/D space so
it won't work.
Thanks again for all the pointers and tips!
-Peter
On Mon, Oct 21, 2024 at 11:54 AM Peter Ekstrom <epekstrom(a)gmail.com> wrote:
Awesome! That appears to work. So even though it has
the same version
number as the one I have tried from another git repo, it is different.
Thank you for this information!
-Peter
On Mon, Oct 21, 2024 at 11:10 AM Nadav Eiron <nadav.eiron(a)gmail.com>
wrote:
> My 11/23 is not accessible, but I believe I've used this version a couple
> of years ago (on a Raspberry Pi):
https://github.com/drboone/vtserver
>
> On Mon, Oct 21, 2024 at 7:45 AM Peter Ekstrom via cctalk <
> cctalk(a)classiccmp.org> wrote:
>
>> Hmm, not sure why yet, but I'm not able to get vtserver to work. I have
>> entered the bootcode manually in ODT, and I have had vtserver send it.
>> It looks like it loads the code and then reads one record but then hangs.
>> I'm wondering if my version of ODT on the CPU board needs something to be
>> handled differently.
>> Btw, the version I have found of vtserver is 2.3.1.5. I can't seem to
>> find
>> anything later than that.
>>
>> I am going to try PDP11GUI but I am waiting on a supported USB-RS232
>> adapter to arrive. The ones I have aren't supported under Windows
>> anymore.
>> I should have it tomorrow.
>>
>> -Peter
>>
>> On Sun, Oct 20, 2024 at 9:30 AM Peter Ekstrom <epekstrom(a)gmail.com>
>> wrote:
>>
>> > Aha! Ok great, I need to look closer at those then. Thank you!
>> >
>> > On Sun, Oct 20, 2024 at 9:23 AM cz <cz(a)alembic.crystel.com> wrote:
>> >
>> >> use pdp11gui or vtserver. They can use ODT to upload a small program
>> to
>> >> the 11 which allows it to send or receive an image to a MCSP or
>> >> RL/RX/Whatever drive. Can be slow (top speed is 9600 or 19200 baud on
>> an
>> >> 11/23) but it does get the job done.
>> >>
>> >> C
>> >>
>> >>
>> >> On 10/20/2024 9:02 AM, Peter Ekstrom wrote:
>> >> > Thank you all for the tips and pointers. I like the idea of
pulling
>> the
>> >> > image off of my real drive, but how would I transfer it between
the
>> pdp
>> >> > and my Linux box with Simh? It is too big for the tu58 emulator.
>> >> >
>> >> > On Sun, Oct 20, 2024 at 03:15 cz via cctalk
<cctalk(a)classiccmp.org
>> >> > <mailto:cctalk@classiccmp.org>> wrote:
>> >> >
>> >> > > If you go this route, be advised, that SIMH creates
RD32
>> disk
>> >> > images
>> >> > > are not the same size as a real RD32. This will likely
cause
>> >> > problems
>> >> > > when writing a SIMH created image to a real disk (and
I'm not
>> >> > talking
>> >> > > about the additional issues that the trailing metadata
on
>> disk
>> >> > images
>> >> > > from the Pizzolato version of SIMH can cause - the
problem
>> I'm
>> >> > > describing is caused by an incorrect disk size value in
>> SIMH).
>> >> >
>> >> > True, I think you can get around this by making them disk in
>> SIMH a
>> >> > couple of blocks smaller.
>> >> >
>> >> > However there is another way. Format your real RD32 with the
>> RQDX3
>> >> > formatter, then once formatted suck it into a file. Then you
>> have an
>> >> > exact replica you can mount in SIMH and load it up.
>> >> >
>> >> > I did this with a 154mb Hitachi ESDI MCSP disk that went
"bad"
>> 30
>> >> years
>> >> > ago and would not boot. Sucked it in, booted RSX11M off a
>> virtual
>> >> > drive,
>> >> > then mounted it. Turns out when I did a purge of old files I
>> deleted
>> >> > the
>> >> > RSX11M.TSK file I was using to boot because I forgot to do a
>> /SAV /
>> >> > WB in
>> >> > VMR to update the boot block to the new file location. Did
that,
>> >> system
>> >> > booted, then copied it back to the "real" Hitachi
disk.
>> >> >
>> >> > Back in operation. :-)
>> >> >
>> >>
>> >>
>>
>