PDP-11 memory shenanigans

[decle]

Hi,

I'm having a bit of a fun getting my head around the PDP-11 memory model, hopefully someone can help. The setup is as follows:

I'm using SIMH to emulate an 11/53 with 256K of RAM. This is running RT-11 v5.0.3 with the XM monitor from an RL02. I'm trying to run a cross assembler written by APh as follows:

.run mx1600 Version of 22-Aug-78 Copyright APh *KB01 PASS1: NO MORE FREE STORAGE .

Whilst the program being assembled is trivially small, you can see I'm running out of memory. I've found a workaround using VBGEXE, like this:

.vbgexe Program? mx1600 Version of 22-Aug-78 Copyright APh *KB01 PASS1: %ALMOST OUT OF STORAGE - SWAPPING USR PASS2: CREF: .

However, I doubt that this was how things were done "back in the day". The RAM configuration seen within RT-11 is:

.show mem ------- Extended Memory -------- Address Module Words Type ------- ------ ----- ---- 17760000 IOPAGE 4096. HDW 01000000 MEMTOP 00176200 ...... 98752. 00170000 SL 1600. PVT 00160000 DU 2048. PVT ------ Low Memory ------- Address Module Words ------- ------ ----- 155564 DL 582. 120042 RMON 7593. 107000 USR 2321. 001000 ..BG.. 17920.

I have tried fiddling with other monitors and tweaking various bits in SYSGEN to try to free more low memory without much success.

My questions are:

• Am I doing something obviously stupid?
• Is my assumption that low memory is the constraint likely to be correct?
• If so, what is a realistic maximum for available low memory on RT-11?
• Is there a way to use extended memory more seamlessly in RT-11 (I'm aware of VRUN on later versions of RT-11, but this would not have been available in 1980-1983 as far as I know)?
• I believe that originally TSX Plus was used in addition to RT-11, would this have made use of extended memory more seamless?

Thanks for any help you can provide.


decle

 

[Scrub]

No its working correct, vgbexe is the way to do it. If you run the small monitor version you can run things without the extra step, you lose out on some ram but most rt-11 programs dont need that much anyway.

 

[decle]

Thanks, this is really helpful. Apologies for my naivety, but could you clarify what you mean by "small monitor version"?

 

[Radix]

If you run TSX (It starts from from RT11SJ) then you can have much more low memory:




Compilers and such like can easily become tricky to run - even linking TSX itself can run out of memory, the trick being to link it on a different volume when running TSX, before exiting TSX and moving the files created to SY:

TSX more or less presents a multi-user RT11SJ environment with more free memory and you can change the disk assignments (for example) for each user..

If you run RT11SJ, you can get 46KB+ free: This is RT-11SB V5.07 (=RT11SJ on earlier versions, the naming changed)

 

[wa2flq]

The earlier versions of RT11 may have used a bit less memory for RMON, though the RT11 team was extremely cautious about increasing its memory over time. RT11BL may be a few bytes less. The only other way I know of to get more memory on real hardware with the RT11SJ monitor is to run a 2K IO page if your equipment allows. I did this on the older monitors, but not the V5.x's. However, I don't think SIMH has a setting that allows this.

 

[Scrub]

Thanks, this is really helpful. Apologies for my naivety, but could you clarify what you mean by "small monitor version"?

I was thinking of the rt11sj that was mentioned by others, it probably stands for single job rather than small

 

[Radix]

Yep - the original ones were Single Job, Foreground-Backround and eXtended Memory

 

[decle]

Cool, thanks. This has been really helpful.

I have a related question, and apologies for my Linux background. mx1600 reads the file name to assemble from what I would know as stdin. In an RT-11 batch, command or ind file is it possible to take an argument from the command line and pass to stdin for a called program? I'm hoping to construct a wrapper around the vbgexe call to mx1600 so that I can execute...

mx16 KB01

and have the script execute...

vbgexe mx1600

passing KB01 in on stdin. Clearly pipes would make this trivial in Unix...

#!/bin/sh echo "$1" | vbgexe mx1600

 

[Radix]

For other programs like compilers and linkers, if you run them from a command file (.com) you can pass the options in the command file - but it depends if your program uses the same conventions - for example:

DICOMP is the DIBOL compiler - it takes input on the command line, here LINK reads options in the command file...

(This is the contents of the command file - executed with @filnam)



It's called DCL or CCL - have a look at Chapter 1 in the attached PDF... Get a coffee first, lol

 

[Hunta]

I've found a workaround using VBGEXE, like this:

In XM monitor version 5.7 (and in some earlier versions), after loading the OS, you can issue the SET VBGEXE RUN command, after which, by default, the OS will run programs in “virtual” memory.