Access to RSTS/E IOPAGE Registers

[Jerome H. Fine]

I require some help with a program which may be of interest
to other hobby users.  The program is:

SHOW  EMULATOR or SHOWEM

and runs under:
(a)  RT-11 both UnMapped and Mapped Monitors
(b)  TSX-Plus
(c)  RUST both RUST/SJ and RUST/XM
(d)  RSTS/E
(e)  RTEM-11

The current Emulators which are detected and displayed
are SimH, Ersatz-11 and V11.  If anyone knows of any
other PDP-11 emulators which can also be included, that
would be of great interest, especially if access to that
emulator for testing is possible.  I have asked for help
in the past about this and the only other PDP-11 emulator
which runs RT-11 compatible programs is Charon which
unfortunately no longer seems to be available or even running.
If anyone can help expand the list, it would be appreciated!!!

Unfortunately, for (d) and (e), I do not have any information
on how to access the IOPAGE registers since SHOWEM
requires access to SR0 (177572) and SR1 (177574) in
addition to the PSW (177776).

I do not believe that RTEM-11 will ever allow a User program
to gain access to the IOPAGE registers, however, RSTS/E
may allow such access.  Does anyone who is reading this
post know if access to the IOPAGE registers is possible
under RSTS/E for a program running in RT-11 compatibility'
mode?  And do you also know how it is done?

If there is no solution, then I will make to current SHOWEM
available to any hobby users who are interested.  Otherwise,
I would prefer to delay until the RSTS/E solution is implemented.

Jerome Fine

[Bill Gunshannon]

In article <50dafa16$0$291$1472...@news.sunsite.dk>,
"Jerome H. Fine" <ever...@nospam.com> writes:
> This is a multi-part message in MIME format.
> --------------010903030908020505070107
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit

All I have to say is any emulator that can be detected as an emulator
is not a very good emulation. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[glen herrmannsfeldt]

In alt.sys.pdp11 Bill Gunshannon <bill...@cs.uofs.edu> wrote:

(snip, someone wrote)

>> The current Emulators which are detected and displayed
>> are SimH, Ersatz-11 and V11. If anyone knows of any
>> other PDP-11 emulators which can also be included, that
>> would be of great interest, especially if access to that
>> emulator for testing is possible. I have asked for help
>> in the past about this and the only other PDP-11 emulator
>> which runs RT-11 compatible programs is Charon which
>> unfortunately no longer seems to be available or even running.
>> If anyone can help expand the list, it would be appreciated!!!

(snip)

> All I have to say is any emulator that can be detected as an
> emulator is not a very good emulation. :-)

That is true, however there has been a tradition of allowing guests
special access to the host, and so require a back door. What exactly
happens if you try to use that door on real hardware is undefined.

IBM VM/CP uses the Diagnose instruction defined to be machine dependent.
The effects of using Diagnose on actual hardware are undefined, possibly
including hardware damage. (More likely, errors that would not appear
in normal operation. You might modify microcode, for example.)

Diagnose, so machine dependent that it doesn't even have an assembler
mnemonic, is a privileged instruction.

Another privileged instruction, STIDP (store processor ID) gives the
serial number of the host processor. There is a tradition for CP to
set the high bits of the serial number that aren't normally set by
real processors. There is, of course, no requirement that those bits
be set, but if they are then the guest knows that it is running under
CP and can use some CP features that it otherwise might not use.

I don't know how that translates to the PDP-11, but maybe it makes
some sense there, too.

Another example, the OS/2 emulation for MS-DOS included a special DOS
device driver that allowed access to host files. I believe the guest
had access to FAT file systems without the special device driver,
but not other file systems. Also, it was faster than emulating the
disk I/O calls.

If the special device driver actually installed under real hardware
the results would likely be strange, but most likely it doesn't.

-- glen

[Jerome H. Fine]

The documentation which I have at present for the RSTS/E and RTEM-11
operating systems is insufficient at present and does not provide access to
the IOPAGE registers. Can anyone help?

>Bill Gunshannon wrote:

>All I have to say is any emulator that can be detected as an emulator
>is not a very good emulation.
>

As Glen Herrmannsfeldt suggests:

"That is true, however there has been a tradition of allowing guests
special access to the host, and so require a back door. What exactly
happens if you try to use that door on real hardware is undefined."

So there are other opinions in regard to this aspect of emulators.

There is also the possibility of implementing an instruction code
which the real hardware does not implement.

In the case of SHOWEM, the code in the program makes use of differences
between how actual hardware reacts to placing values in some of the
IOPAGE registers which can never arise as a result of executing any
possible operations which have been defined by the manufacturer of
actual hardware.

For example, if memory is always required within a certain address range
in order to execute any code at all, then a trap which specifies an
address in that range which results in an address from that address
range being placed into the IOPAGE register will never be possible
using actual hardware.

It has been found that the code used to implement PDP-11 emulators
tends to result in different values from each other as well as being
different from the values which result on actual hardware when specific
instructions are executed for which there are no definitions when used
with any actual hardware CPU on the PDP-11.

In any case, at present SHOWEM is able to detect SimH, Ersatz-11 and
V11 under RT-11, TSX-Plus and RUST. The key requirement is access to
the IOPAGE registers. There are different EMT requests available in
RT-11 and TSX-Plus to provide this access along with other EMT requests
which provide information as to which operating system is executing.

The documentation which I have at present for the RSTS/E and RTEM-11
operating systems is insufficient at present and does not provide
access to the IOPAGE registers. Can anyone help?

Jerome Fine

[Johnny Billquist]

Just to point out, there exists both semi-undocumented diagnostics
instructions that might do very different things on different PDP-11s.
Some if them do have mnemonics, but none that MACRO-11 recognizes (MED
for example), and some processors (well, only the 11/70 as far as I
know) do have a special register holding the serial number.
And newer processors have a type register.

Johnny

[Johnny Billquist]

I would seriously doubt you could access the IOPAGE from RSTS/E as well,
as that would allow you to circumvent the OS protection.

That said, I can test running whatever you cook up in RTEM-11, if you
want to. (Or contact me, and I can get you access to RTEM-11 yourself.)

Johnny

[glen herrmannsfeldt]

In alt.sys.pdp11 Johnny Billquist <b...@softjar.se> wrote:

(snip, I wrote)

>> IBM VM/CP uses the Diagnose instruction defined to be machine dependent.
>> The effects of using Diagnose on actual hardware are undefined, possibly
>> including hardware damage. (More likely, errors that would not appear
>> in normal operation. You might modify microcode, for example.)

>> Diagnose, so machine dependent that it doesn't even have an assembler
>> mnemonic, is a privileged instruction.

(snip)

>> I don't know how that translates to the PDP-11, but maybe it makes
>> some sense there, too.

> Just to point out, there exists both semi-undocumented diagnostics
> instructions that might do very different things on different PDP-11s.
> Some if them do have mnemonics, but none that MACRO-11 recognizes (MED
> for example),

There is a macro, DIAG, to generate the appropriate form of Diagnose,
for CP calls, so, even though it isn't known to assemblers as an
instruction, it can still be used like one.

But the important thing is that the opcode is reserved.

There is one other S/360 reserved opcode, X'00' is not implemented as
an instruction, and is supposed to stay that way.

> and some processors (well, only the 11/70 as far as I
> know) do have a special register holding the serial number.
> And newer processors have a type register.

How many bits for serial number? And are they always decimal numbers?
(or octal numbers?) IBM warns that they could be hexadecimal.
(Presumably it matches the number stamped on the outside of the box.)

-- glen

[Johnny Billquist]

On 2012-12-27 22:25, glen herrmannsfeldt wrote:
> In alt.sys.pdp11 Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, I wrote)
>>> IBM VM/CP uses the Diagnose instruction defined to be machine dependent.
>>> The effects of using Diagnose on actual hardware are undefined, possibly
>>> including hardware damage. (More likely, errors that would not appear
>>> in normal operation. You might modify microcode, for example.)
>
>>> Diagnose, so machine dependent that it doesn't even have an assembler
>>> mnemonic, is a privileged instruction.
>
> (snip)
>>> I don't know how that translates to the PDP-11, but maybe it makes
>>> some sense there, too.
>
>> Just to point out, there exists both semi-undocumented diagnostics
>> instructions that might do very different things on different PDP-11s.
>> Some if them do have mnemonics, but none that MACRO-11 recognizes (MED
>> for example),
>
> There is a macro, DIAG, to generate the appropriate form of Diagnose,
> for CP calls, so, even though it isn't known to assemblers as an
> instruction, it can still be used like one.
>
> But the important thing is that the opcode is reserved.
>
> There is one other S/360 reserved opcode, X'00' is not implemented as
> an instruction, and is supposed to stay that way.

On the PDP-11, the diagnostics opcode(s) are more undefined. Some
processors don't have any, others have several. And while they all fall
in the same range, I believe, they are just reserved instruction traps
on other processors. And might do totally different things on the ones
where they do exist. So it's extremely hard to use them in any way until
you've really figured out what processor you are...

>> and some processors (well, only the 11/70 as far as I
>> know) do have a special register holding the serial number.
>> And newer processors have a type register.
>
> How many bits for serial number? And are they always decimal numbers?
> (or octal numbers?) IBM warns that they could be hexadecimal.
> (Presumably it matches the number stamped on the outside of the box.)

Meh. It's just a 16-bit number (if I remember right). Even more silly is
that it's taken from a set of dip switches on one CPU board, so you can
just change it to anything on your machine if you want to.

The type register have a bunch of unused values, as well as most
machines using the J11 having a second register telling what specific
model you have, where you also have a bunch of undefined bits you could
play with.

So it would probably make sense to stick something in where software in
general wouldn't care for an emulated machine, so that code that really
wants to know could figure it out, even though code not aware would
believe it's just a known systems that the emulator implements without
giving it away.

Johnny

[paramucho]

On Thu, 27 Dec 2012 22:16:00 +0100, Johnny Billquist <b...@softjar.se>
wrote:

This old thread confirms that there is no (published) access method:

http://www.classiccmp.org/pipermail/cctech/2003-March/086350.html

Which says in part:

In order to talk directly to a device under RSTS you need to be in
kernel mode, not user mode. I am not aware of a RSTS-native way to
do something like RSX or VMS connect-to-interrupt directives or the
like. Similarly there is not a (published) way to map I/O space to
user space. This is really the kind of thing you need to accomplish
what you are asking.

I had a quick look at the various internals books but couldn't see
anything interesting.


Ian

[Johnny Billquist]

Also, the RSX CINT$ directive isn't really that interesting. All it does
is establish an interrupt vector which will become a call to code in
your program when an interrupt happens. It does not in general give you
any access to the IO Page. (Although, when you are running in interrupt
context, you are of course in kernel mode, with the IO page where you
would expect it.)
The common way to get access to the IO page in RSX is to build your
program privileged, and run it. Then it will have the IO page mapped, as
well as being able to switch to kernel mode if needed.

Of course, a normal used can't run such a program...

(And the CINT$ system call can also only be used by a privileged program...)


Johnny

[paramucho]

On Fri, 28 Dec 2012 16:01:30 +0100, Johnny Billquist <b...@softjar.se>

I've never used RTEM, but I have wondered whether a program running
under RTEM can issue RSX exec directives as well as RT-11 EMTs?




Ian

[Johnny Billquist]

I haven't tried. But it might be, since I suspect they set up an SST
handler for EMT traps in RTEM, and the EMT SST handler don't get called
for known EMTs. But that is guessing on my part. You are free to test on
MIM yourself. ;-)

Johnny

[jgharston]

Jerome H. Fine wrote:
> and runs under:
> (a)  RT-11 both UnMapped and Mapped Monitors
> (b)  TSX-Plus
> (c)  RUST both RUST/SJ and RUST/XM
> (d)  RSTS/E
> (e)  RTEM-11

... PDP UNIX ...?

And any chance of a link to a download?

JGH

[Johnny Billquist]

I think Jerome's code runs under RT-11. And all the things listed above
are RT-11 environments... I don't expect Unix to fit in there...

Johnny

[Jerome H. Fine]

The source code and an RT-11 executable file will be
available as soon as it can be verified that RSTS/E
and RTEM-11 do not support SHOWEM.

There are two requirements:

(a) Access to the IOPAGE registers at least in USER MODE.
(b) If the SR0 (177572), SR1 (177574) and PSW (177776)
registers are not explicitly available, then RT-11 uses the
.TrpSet EMT request to avoid an abort.

SHOWEM disables interrupts and, when required, swaps
about 200 words of code and data to 10000 octal in the
PAR0 portion of physical memory, then executes a trap
routine in KERNEL MODE.

All of RT-11, TSX-Plus and RUST support these two requirements.
If UNIX can also run a file which runs under RT-11, it would
be possible to include the extra code needed for UNIX as well.
Can you provide details? RT-11 uses words 40 to 50 in block
zero of the executable file to inform the loader where to start
the program, the location of the stack and the required memory.
The program starts at location 1000 in block one. If there is
sufficient compatibility between RT-11 and UNIX on how a
program is loaded and started, then it should be possible to
test under UNIX as well if access the the IOAGE registers
is possible.

NOTE that TSX-Plus requires a user to have MEMMAP privilege
to be able to directly access the IOAGE registers. This is NOT a
normal privilege since it opens the complete PDP-11 to any
user with access to the IOPAGE registers.

Jerome Fine

[Johnny Billquist]

On 2012-12-31 01:34, Jerome H. Fine wrote:
> >jgharston wrote:
>
>>> Jerome H. Fine wrote:
>>
>>
>>> and runs under:
>>> (a) RT-11 both UnMapped and Mapped Monitors
>>> (b) TSX-Plus
>>> (c) RUST both RUST/SJ and RUST/XM
>>> (d) RSTS/E
>>> (e) RTEM-11
>>>
>> ... PDP UNIX ...?
>>
>> And any chance of a link to a download?
>>
>> JGH
>>
> The source code and an RT-11 executable file will be
> available as soon as it can be verified that RSTS/E
> and RTEM-11 do not support SHOWEM.

I can assure you, they do not. You cannot turn off interrupts in either,
without going to kernel mode, which neither of those OSes allows your
program to do either, even apart from the fact that you don't have
access to the I/O page.

> There are two requirements:
>
> (a) Access to the IOPAGE registers at least in USER MODE.

Neither RSTS/E nor RTEM-11 will give you that.

> (b) If the SR0 (177572), SR1 (177574) and PSW (177776)
> registers are not explicitly available, then RT-11 uses the
> .TrpSet EMT request to avoid an abort.

Since (a) is already invalid, this becomes irrelevant.

> SHOWEM disables interrupts and, when required, swaps
> about 200 words of code and data to 10000 octal in the
> PAR0 portion of physical memory, then executes a trap
> routine in KERNEL MODE.
>
> All of RT-11, TSX-Plus and RUST support these two requirements.

Right.

> If UNIX can also run a file which runs under RT-11, it would
> be possible to include the extra code needed for UNIX as well.

Unix is way different in many ways. Think of it more in the vein of RSX
or RSTS/E, and you come closer. Unix also will not allow your
requirements, even apart from the fact that binary files have a totally
different format (search for the a.out format if you want details).
Also, system calls are also totally different.

> Can you provide details? RT-11 uses words 40 to 50 in block
> zero of the executable file to inform the loader where to start
> the program, the location of the stack and the required memory.
> The program starts at location 1000 in block one. If there is
> sufficient compatibility between RT-11 and UNIX on how a
> program is loaded and started, then it should be possible to
> test under UNIX as well if access the the IOAGE registers
> is possible.

It is totally incompatible. Not to mention that the whole file system
design is also totally incompatible, as well as the view of what a file
looks like, or appears, and how devices act, and just about everything else.

Johnny

[paramucho]

On Sun, 30 Dec 2012 19:34:19 -0500, "Jerome H. Fine"
<ever...@nospam.com> wrote:


>
>All of RT-11, TSX-Plus and RUST support these two requirements.
>If UNIX can also run a file which runs under RT-11, it would
>be possible to include the extra code needed for UNIX as well.
>Can you provide details? RT-11 uses words 40 to 50 in block
>zero of the executable file to inform the loader where to start
>the program, the location of the stack and the required memory.
>The program starts at location 1000 in block one. If there is
>sufficient compatibility between RT-11 and UNIX on how a
>program is loaded and started, then it should be possible to
>test under UNIX as well if access the the IOAGE registers
>is possible.

What is being asked is whether an RT-11 program and a Unix program can
co-exist in the same file image, with the understanding that the RT-11
code in the image would use RT-11 EMTs and the Unix code would use
Unix system calls.

In fact, RT-11 and Ancient Unix programs probably can co-exist. A Unix
program begins with an 8-word header consisting of something like
this:

00: .word magic number
02: .word code size
04: .word data size
06: .word heap size
10: .word symbols?
12: .word start address
14: .word unused
16: .word relflg

where the magic number is:

407 vanilla
410 read-only code
411 I/D separation
405 overlaid

(I got this data from a Unix emulator I sketched out for
RUST/XM, and my memory is a bit scratchy, so no guarantees and
I don't remember which version I used as a model.)

The one possible collision with an RT-11 image is the first location.
RT-11 flags some images as "VIRTUAL" by placing rad50 "VIR" in
location zero. I don't see a problem.

By the way, co-existing images are common in RT-11. Some device
drivers also be run as standard utility programs (to handle setup etc,
e.g. LD:). The RUST general purpose boot utility BOOT.SAV can be
treated as a standard RT-11 program or as a bootable image.

On the other hand, there's no reason not to use separate images.

All that said, as has been pointed out, Ancient Unix was a timeshare
system, not a real-time system, and does not provide access to the I/O
page, so the current tests which require I/O page access are not
available.

However, it occurs to me that it's probably possible to use relative
instruction times as signatures for a given CPU or emulator. All that
is required for that kind of test is a mark time (equivalent) system
call. In a multi-process system and on emulators you'd need iron out
differences caused by scheduling, but that could be handled by
rerunning the tests until a stable result was required.

However, the only "mark time" request that Ancient Unix supplies
(Alarm) has a 1-second granularity--that's no use unless you willing
to wait about 20 seconds for a result. RSTS doesn't seem to
support mark time. RSX does, but I don't know if it maps through to
RTEM (it probably does since I think KED uses it). Most RT-11 systems
support mark time, and those that don't can be fixed by stealing the
clock vector. All RUST systems support mark time. I don't know about
TSX, but I'd guess TSX-plus supports it.

Ian

[Bob Eager]

On Mon, 31 Dec 2012 16:04:42 +0000, paramucho wrote:

> What is being asked is whether an RT-11 program and a Unix program can
> co-exist in the same file image, with the understanding that the RT-11
> code in the image would use RT-11 EMTs and the Unix code would use Unix
> system calls.
>
> In fact, RT-11 and Ancient Unix programs probably can co-exist. A Unix
> program begins with an 8-word header consisting of something like this:
>
> 00: .word magic number 02: .word code size 04: .word
data size 06: .word
> heap size 10: .word symbols?
> 12: .word start address 14: .word unused 16: .word
relflg
>
> where the magic number is:
>
> 407 vanilla 410 read-only code 411 I/D separation 405
overlaid
>
> (I got this data from a Unix emulator I sketched out for RUST/XM, and my
> memory is a bit scratchy, so no guarantees and I don't remember which
> version I used as a model.)

The original idea was that the 407 was a branch instruction that skipp3ed
the header, allowing standalone programs to be started at the first
instruction of the image.

> The one possible collision with an RT-11 image is the first location.
> RT-11 flags some images as "VIRTUAL" by placing rad50 "VIR" in location
> zero. I don't see a problem.

UNIX would no longer recognise the image as executable.

> On the other hand, there's no reason not to use separate images.

Much easier.

> All that said, as has been pointed out, Ancient Unix was a timeshare
> system, not a real-time system, and does not provide access to the I/O
> page, so the current tests which require I/O page access are not
> available.

It does provide access for the super-user, and for any privileged
program. One simply sets the programs as 'set user-id' with the root
user. Then it can access the file /dev/mem, which of course includes the
I/O page AFAIR.

--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning surge protection* - a w_tom conductor

[Johnny Billquist]

On 2012-12-31 17:04, paramucho wrote:
> On Sun, 30 Dec 2012 19:34:19 -0500, "Jerome H. Fine"
> <ever...@nospam.com> wrote:
>
>
>>
>> All of RT-11, TSX-Plus and RUST support these two requirements.
>> If UNIX can also run a file which runs under RT-11, it would
>> be possible to include the extra code needed for UNIX as well.
>> Can you provide details? RT-11 uses words 40 to 50 in block
>> zero of the executable file to inform the loader where to start
>> the program, the location of the stack and the required memory.
>> The program starts at location 1000 in block one. If there is
>> sufficient compatibility between RT-11 and UNIX on how a
>> program is loaded and started, then it should be possible to
>> test under UNIX as well if access the the IOAGE registers
>> is possible.
>
> What is being asked is whether an RT-11 program and a Unix program can
> co-exist in the same file image, with the understanding that the RT-11
> code in the image would use RT-11 EMTs and the Unix code would use
> Unix system calls.

I thought the question was about running the RT-11 program on Unix...
The actual layout is like a follow-on issue to that question.
It might be that you could create a binary that could load and run on
both systems, but with different bits that was the executable. I don't
know. Seems like it would become very complex to say the least.

How would you make the RT-11 use one set of EMTs, and the Unix code
another set (I don't even think Unix uses the EMT for system calls.)

> In fact, RT-11 and Ancient Unix programs probably can co-exist. A Unix
> program begins with an 8-word header consisting of something like
> this:
>
> 00: .word magic number
> 02: .word code size
> 04: .word data size
> 06: .word heap size
> 10: .word symbols?
> 12: .word start address
> 14: .word unused
> 16: .word relflg
>
> where the magic number is:
>
> 407 vanilla
> 410 read-only code
> 411 I/D separation
> 405 overlaid

[...]
Note that the magic number is actually a branch instruction around the
rest of the header. ;-)

Which also tells you that the header isn't necessarily 8 words.

> (I got this data from a Unix emulator I sketched out for
> RUST/XM, and my memory is a bit scratchy, so no guarantees and
> I don't remember which version I used as a model.)

It's all documented inside Unix, if someone really wants to know.
Probably even in the man-pages of 2.11BSD... I can check later, if
someone really wants details.

> The one possible collision with an RT-11 image is the first location.
> RT-11 flags some images as "VIRTUAL" by placing rad50 "VIR" in
> location zero. I don't see a problem.

Except of course, if the first located holds R50("VIR"), then Unix will
totally refuse to run it.

> By the way, co-existing images are common in RT-11. Some device
> drivers also be run as standard utility programs (to handle setup etc,
> e.g. LD:). The RUST general purpose boot utility BOOT.SAV can be
> treated as a standard RT-11 program or as a bootable image.

That's different than in RSX, for example.

> On the other hand, there's no reason not to use separate images.

Right.

> All that said, as has been pointed out, Ancient Unix was a timeshare
> system, not a real-time system, and does not provide access to the I/O
> page, so the current tests which require I/O page access are not
> available.

Correct.

> However, it occurs to me that it's probably possible to use relative
> instruction times as signatures for a given CPU or emulator. All that
> is required for that kind of test is a mark time (equivalent) system
> call. In a multi-process system and on emulators you'd need iron out
> differences caused by scheduling, but that could be handled by
> rerunning the tests until a stable result was required.

Except a good emulator should give the same timings... :-)

> However, the only "mark time" request that Ancient Unix supplies
> (Alarm) has a 1-second granularity--that's no use unless you willing
> to wait about 20 seconds for a result. RSTS doesn't seem to
> support mark time. RSX does, but I don't know if it maps through to
> RTEM (it probably does since I think KED uses it). Most RT-11 systems
> support mark time, and those that don't can be fixed by stealing the
> clock vector. All RUST systems support mark time. I don't know about
> TSX, but I'd guess TSX-plus supports it.

Yeah, Unix timing isn't something to boast about either.
RSTS/E isn't too great in this area either.
I would suspect that RTEM gives some timer interface, since RT-11 have
it, and RTEM is supposed to give you most of the RT-11 environment.
System calls that can be implemented I would expect to be implemented.

Johnny

[Johnny Billquist]

On 2012-12-31 17:23, Bob Eager wrote:
> On Mon, 31 Dec 2012 16:04:42 +0000, paramucho wrote:
>
>> What is being asked is whether an RT-11 program and a Unix program can
>> co-exist in the same file image, with the understanding that the RT-11
>> code in the image would use RT-11 EMTs and the Unix code would use Unix
>> system calls.
>>
>> In fact, RT-11 and Ancient Unix programs probably can co-exist. A Unix
>> program begins with an 8-word header consisting of something like this:
>>
>> 00: .word magic number 02: .word code size 04: .word
> data size 06: .word
>> heap size 10: .word symbols?
>> 12: .word start address 14: .word unused 16: .word
> relflg
>>
>> where the magic number is:
>>
>> 407 vanilla 410 read-only code 411 I/D separation 405
> overlaid
>>
>> (I got this data from a Unix emulator I sketched out for RUST/XM, and my
>> memory is a bit scratchy, so no guarantees and I don't remember which
>> version I used as a model.)
>
> The original idea was that the 407 was a branch instruction that skipp3ed
> the header, allowing standalone programs to be started at the first
> instruction of the image.

Yes.

>> All that said, as has been pointed out, Ancient Unix was a timeshare
>> system, not a real-time system, and does not provide access to the I/O
>> page, so the current tests which require I/O page access are not
>> available.
>
> It does provide access for the super-user, and for any privileged
> program. One simply sets the programs as 'set user-id' with the root
> user. Then it can access the file /dev/mem, which of course includes the
> I/O page AFAIR.

Right. However, that means accessing the I/O page through a device
driver. If you are accessing registers that changes depending on
execution, you might not be reading what you really are looking for.

Johnny

[paramucho]

On 31 Dec 2012 16:23:30 GMT, Bob Eager <news...@eager.cx> wrote:

>On Mon, 31 Dec 2012 16:04:42 +0000, paramucho wrote:
>

<snip>

>
>> The one possible collision with an RT-11 image is the first location.
>> RT-11 flags some images as "VIRTUAL" by placing rad50 "VIR" in location
>> zero. I don't see a problem.
>
>UNIX would no longer recognise the image as executable.

The "VIR" marking would not be required for the image in question.

>> On the other hand, there's no reason not to use separate images.
>
>Much easier.
>
>> All that said, as has been pointed out, Ancient Unix was a timeshare
>> system, not a real-time system, and does not provide access to the I/O
>> page, so the current tests which require I/O page access are not
>> available.
>
>It does provide access for the super-user, and for any privileged
>program. One simply sets the programs as 'set user-id' with the root
>user. Then it can access the file /dev/mem, which of course includes the
>I/O page AFAIR.

I should have pointed out that the software needs to manipulate
registers in I/O space.



Ian

[paramucho]

On Mon, 31 Dec 2012 17:30:59 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>> What is being asked is whether an RT-11 program and a Unix program can
>> co-exist in the same file image, with the understanding that the RT-11
>> code in the image would use RT-11 EMTs and the Unix code would use
>> Unix system calls.
>
>I thought the question was about running the RT-11 program on Unix...
>The actual layout is like a follow-on issue to that question.
>It might be that you could create a binary that could load and run on
>both systems, but with different bits that was the executable. I don't
>know. Seems like it would become very complex to say the least.
>
>How would you make the RT-11 use one set of EMTs, and the Unix code
>another set (I don't even think Unix uses the EMT for system calls.)

The program would have different entry points for RT-11 and Unix, so
it can easily determine which system it's running under. It would then
use the appropriate system calls. Unix uses TRAP rather than EMT for
system calls.

>> The one possible collision with an RT-11 image is the first location.
>> RT-11 flags some images as "VIRTUAL" by placing rad50 "VIR" in
>> location zero. I don't see a problem.
>
>Except of course, if the first located holds R50("VIR"), then Unix will
>totally refuse to run it.

That wouldn't be necessary, so not a problem.

<snip>

>> However, the only "mark time" request that Ancient Unix supplies
>> (Alarm) has a 1-second granularity--that's no use unless you willing
>> to wait about 20 seconds for a result. RSTS doesn't seem to
>> support mark time. RSX does, but I don't know if it maps through to
>> RTEM (it probably does since I think KED uses it). Most RT-11 systems
>> support mark time, and those that don't can be fixed by stealing the
>> clock vector. All RUST systems support mark time. I don't know about
>> TSX, but I'd guess TSX-plus supports it.
>
>Yeah, Unix timing isn't something to boast about either.
>RSTS/E isn't too great in this area either.
>I would suspect that RTEM gives some timer interface, since RT-11 have
>it, and RTEM is supposed to give you most of the RT-11 environment.
>System calls that can be implemented I would expect to be implemented.

Alas, I haven't been able to locate any decent RTEM documentation
on-line.


Ian

[Johnny Billquist]

On 2013-01-01 05:55, paramucho wrote:
> On Mon, 31 Dec 2012 17:30:59 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
> <snip>
>>> What is being asked is whether an RT-11 program and a Unix program can
>>> co-exist in the same file image, with the understanding that the RT-11
>>> code in the image would use RT-11 EMTs and the Unix code would use
>>> Unix system calls.
>>
>> I thought the question was about running the RT-11 program on Unix...
>> The actual layout is like a follow-on issue to that question.
>> It might be that you could create a binary that could load and run on
>> both systems, but with different bits that was the executable. I don't
>> know. Seems like it would become very complex to say the least.
>>
>> How would you make the RT-11 use one set of EMTs, and the Unix code
>> another set (I don't even think Unix uses the EMT for system calls.)
>
> The program would have different entry points for RT-11 and Unix, so
> it can easily determine which system it's running under. It would then
> use the appropriate system calls. Unix uses TRAP rather than EMT for
> system calls.

Hmm. I guess that could theoretically work. It would take some more
serious analysis to see if an RT-11 image header could co-exist with a
Unix one. Not something I'm going to dig into.
I suspect that RSX and Unix image headers are not mergable. But I
haven't looked at that either.

>>> However, the only "mark time" request that Ancient Unix supplies
>>> (Alarm) has a 1-second granularity--that's no use unless you willing
>>> to wait about 20 seconds for a result. RSTS doesn't seem to
>>> support mark time. RSX does, but I don't know if it maps through to
>>> RTEM (it probably does since I think KED uses it). Most RT-11 systems
>>> support mark time, and those that don't can be fixed by stealing the
>>> clock vector. All RUST systems support mark time. I don't know about
>>> TSX, but I'd guess TSX-plus supports it.
>>
>> Yeah, Unix timing isn't something to boast about either.
>> RSTS/E isn't too great in this area either.
>> I would suspect that RTEM gives some timer interface, since RT-11 have
>> it, and RTEM is supposed to give you most of the RT-11 environment.
>> System calls that can be implemented I would expect to be implemented.
>
> Alas, I haven't been able to locate any decent RTEM documentation
> on-line.

Me neither. But I can run programs to test things. :-)
Except I don't know RT-11...

Johnny

[paramucho]

On Tue, 01 Jan 2013 19:37:04 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

I found the RTEM doc set and I will try to scan it sometime. RTEM is
based on the RT-11/FB monitor and supports .MRKT "mark time".

I started looking at taking some of RT-11 monitor code and producing
an RSX image which would run a single RT-11 program, which made me
look at the low-memory compatibility between RT-11 and RSX-11.

In memory, an RSX task begins with the "task header". RT-11 programs
use low memory differently, obviously, and their are conflicts.

Version 2 RSX documentation says that a system copy of the header is
copied back to task memory before checkpointing. Version 3 doesn't
seem to say that.

I played around with the task header of PIP in a live RSX system
(running under V11). It didn't seem to worry about me trashing most of
the entries, and the ones that it didn't like me altering wouldn't be
active in an RT-11 program (FCS pointer etc).

The one location which is heavily used is the DSW which receives the
status of the preceding RSX system call. I don't know how RTEM manages
the DSW. If it was me, I'd probably be context switching it
before/after issuing an exec. directive on behalf of an RT-11 program,
but their may be more sophisticated ways of managing the DSW.



Ian

[Johnny Billquist]

The system header is handled differently on mapped and unmapped systems,
as well. The actual data used by the kernel is not stuff that you are
allowed to manipulate in the program, since that would allow you to
circumvent security. However, data was stored back in memory for
checkpointing, since it needed to be preserved somehow. In M+, the data
is never stored out, since headers are kept out of pool anyway, so they
can be kept around for checkpointed tasks.

> I played around with the task header of PIP in a live RSX system
> (running under V11). It didn't seem to worry about me trashing most of
> the entries, and the ones that it didn't like me altering wouldn't be
> active in an RT-11 program (FCS pointer etc).

Most of the stuff definitely don't care if you trash it, however, your
written data might be overwritten again by RSX, if you get checkpointed.

The only stuff down that that do matter are things used at the user
level, which you noticed. You have FCS pointers, $DSW, but I think there
might also be some overlay pointers if you use that, and I can't
remember what else. But stuff used by libraries that you link,
essentially. TKB knows an awful lot about FCS...

> The one location which is heavily used is the DSW which receives the
> status of the preceding RSX system call. I don't know how RTEM manages
> the DSW. If it was me, I'd probably be context switching it
> before/after issuing an exec. directive on behalf of an RT-11 program,
> but their may be more sophisticated ways of managing the DSW.

Quite possible they just save that location. I don't really know.
As for FCS, they might just not use it...

Nice with the documentation. Would be nice to read it...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[paramucho]

On Sun, 13 Jan 2013 15:13:01 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> I started looking at taking some of RT-11 monitor code and producing
>> an RSX image which would run a single RT-11 program, which made me
>> look at the low-memory compatibility between RT-11 and RSX-11.

Some of my own RUSTboot and RUST/SJ monitor code of course.

>> In memory, an RSX task begins with the "task header". RT-11 programs
>> use low memory differently, obviously, and their are conflicts.
>>
>> Version 2 RSX documentation says that a system copy of the header is
>> copied back to task memory before checkpointing. Version 3 doesn't
>> seem to say that.
>
>The system header is handled differently on mapped and unmapped systems,
>as well. The actual data used by the kernel is not stuff that you are
>allowed to manipulate in the program, since that would allow you to
>circumvent security. However, data was stored back in memory for
>checkpointing, since it needed to be preserved somehow. In M+, the data
>is never stored out, since headers are kept out of pool anyway, so they
>can be kept around for checkpointed tasks.
>>
>> I played around with the task header of PIP in a live RSX system
>> (running under V11). It didn't seem to worry about me trashing most of
>> the entries, and the ones that it didn't like me altering wouldn't be
>> active in an RT-11 program (FCS pointer etc).
>
>Most of the stuff definitely don't care if you trash it, however, your
>written data might be overwritten again by RSX, if you get checkpointed.

I got some time to actually read the RTEM docs today, which tells me:

RTEM runs under M+ only with "Task headers out of pool" support. I
guess that's standard.

Under RSX-11M V4 you have to edit SGNEXEC.CND to get it to process a
section titled ";RT EMULATOR" by removing a commented jump, and add
".SETF $RTE" to SGNSTAND.CMD.

To enable executive support for RT emulation you apparently have to
answer affirmatively to "32A. RT-11 emulation support [Y/N]" which
results in "A$$HDR=0 :ALTERNATE TASK HEADER SUPPORT" being included in
RSXMC.MAC.

A search of the system sources for "A$$HDR" isolates the required
code.

So, one way or another RTEM requires a system solution to task header
conflict.

>Quite possible they just save that location. I don't really know.
>As for FCS, they might just not use it...

RTEM wouldn't use FCS, libraries or overlays. RTEM doesn't support
native RSX-11 file systems. All they need is logical I/O to volumes or
files formatted as RT-11 disks (except for the terminal etc.)

The utility RTX that I'm sketching would access native RSX-11 file
systems and in fact probably wouldn't support RT-11 volumes ('cos both
would cost to much memory).

>Nice with the documentation. Would be nice to read it...

All I need to do is to learn how to scan without falling asleep and
I'll make it available.

Ian

[John Santos]

In article <50dafa16$0$291$1472...@news.sunsite.dk>,
ever...@nospam.com says...>

> I require some help with a program which may be of interest
> to other hobby users. The program is:
>
> SHOW EMULATOR or SHOWEM
>

> and runs under:
> (a) RT-11 both UnMapped and Mapped Monitors
> (b) TSX-Plus
> (c) RUST both RUST/SJ and RUST/XM
> (d) RSTS/E
> (e) RTEM-11
>

> The current Emulators which are detected and displayed
> are SimH, Ersatz-11 and V11. If anyone knows of any
> other PDP-11 emulators which can also be included, that
> would be of great interest, especially if access to that
> emulator for testing is possible. I have asked for help
> in the past about this and the only other PDP-11 emulator
> which runs RT-11 compatible programs is Charon which
> unfortunately no longer seems to be available or even running.
> If anyone can help expand the list, it would be appreciated!!!
>
> Unfortunately, for (d) and (e), I do not have any information
> on how to access the IOPAGE registers since SHOWEM
> requires access to SR0 (177572) and SR1 (177574) in
> addition to the PSW (177776).

Read access or read/write access?

>
> I do not believe that RTEM-11 will ever allow a User program
> to gain access to the IOPAGE registers, however, RSTS/E
> may allow such access. Does anyone who is reading this
> post know if access to the IOPAGE registers is possible
> under RSTS/E for a program running in RT-11 compatibility'
> mode? And do you also know how it is done?

RSTS/E, in BASIC+, has a PEEK function that returns the contents
of a word in the kernal's currently mapped address space. You
can use this to examine monitor data structures as well as the
I/O page. You or your program must be privileged to do this.
(See SYSTAT, for example, for a program that displays monitor
data structures using PEEK().)

It is also possible to poke the kernel (write to its address
space) using a special SYS() call. Originally, you had to be
logged in to the [1,1] account to do this, but I think since
V9.0, there may be a privilege that controls this.

I think it is possible to do both these operations from the
RT11 RTS, but would have to read the manuals (Programmer's
Manual for BASIC+ and System Directives Manual for RT11) to
find out all the details. Are these available online anywhere?

>
> If there is no solution, then I will make to current SHOWEM
> available to any hobby users who are interested. Otherwise,
> I would prefer to delay until the RSTS/E solution is implemented.
>

> Jerome Fine

HTH

--
John

[Hartmut Brandt]

On Sun, 13 Jan 2013, Johnny Billquist wrote:

JB>On 2013-01-13 09:01, paramucho wrote:
JB>> On Tue, 01 Jan 2013 19:37:04 +0100, Johnny Billquist <b...@softjar.se>
JB>> wrote:
JB>>
JB>> <snip>
JB>> > > The program would have different entry points for RT-11 and Unix, so
JB>> > > it can easily determine which system it's running under. It would then
JB>> > > use the appropriate system calls. Unix uses TRAP rather than EMT for
JB>> > > system calls.
JB>> >
JB>> > Hmm. I guess that could theoretically work. It would take some more
JB>> > serious analysis to see if an RT-11 image header could co-exist with a
JB>> > Unix one. Not something I'm going to dig into.
JB>> > I suspect that RSX and Unix image headers are not mergable. But I
JB>> > haven't looked at that either.
JB>> >
JB>> > > > > However, the only "mark time" request that Ancient Unix supplies
JB>> > > > > (Alarm) has a 1-second granularity--that's no use unless you
JB>> > > > > willing
JB>> > > > > to wait about 20 seconds for a result. RSTS doesn't seem to
JB>> > > > > support mark time. RSX does, but I don't know if it maps through to
JB>> > > > > RTEM (it probably does since I think KED uses it). Most RT-11
JB>> > > > > systems
JB>> > > > > support mark time, and those that don't can be fixed by stealing
JB>> > > > > the
JB>> > > > > clock vector. All RUST systems support mark time. I don't know
JB>> > > > > about
JB>> > > > > TSX, but I'd guess TSX-plus supports it.
JB>> > > >
JB>> > > > Yeah, Unix timing isn't something to boast about either.
JB>> > > > RSTS/E isn't too great in this area either.
JB>> > > > I would suspect that RTEM gives some timer interface, since RT-11
JB>> > > > have
JB>> > > > it, and RTEM is supposed to give you most of the RT-11 environment.
JB>> > > > System calls that can be implemented I would expect to be
JB>> > > > implemented.
JB>> > >
JB>> > > Alas, I haven't been able to locate any decent RTEM documentation
JB>> > > on-line.
JB>> >
JB>> > Me neither. But I can run programs to test things. :-)
JB>> > Except I don't know RT-11...
JB>>
JB>> I found the RTEM doc set and I will try to scan it sometime. RTEM is
JB>> based on the RT-11/FB monitor and supports .MRKT "mark time".
JB>>
JB>> I started looking at taking some of RT-11 monitor code and producing
JB>> an RSX image which would run a single RT-11 program, which made me
JB>> look at the low-memory compatibility between RT-11 and RSX-11.
JB>>
JB>> In memory, an RSX task begins with the "task header". RT-11 programs
JB>> use low memory differently, obviously, and their are conflicts.
JB>>
JB>> Version 2 RSX documentation says that a system copy of the header is
JB>> copied back to task memory before checkpointing. Version 3 doesn't
JB>> seem to say that.
JB>
JB>The system header is handled differently on mapped and unmapped systems, as
JB>well. The actual data used by the kernel is not stuff that you are allowed to
JB>manipulate in the program, since that would allow you to circumvent security.
JB>However, data was stored back in memory for checkpointing, since it needed to
JB>be preserved somehow. In M+, the data is never stored out, since headers are
JB>kept out of pool anyway, so they can be kept around for checkpointed tasks.
JB>
JB>> I played around with the task header of PIP in a live RSX system
JB>> (running under V11). It didn't seem to worry about me trashing most of
JB>> the entries, and the ones that it didn't like me altering wouldn't be
JB>> active in an RT-11 program (FCS pointer etc).
JB>
JB>Most of the stuff definitely don't care if you trash it, however, your
JB>written data might be overwritten again by RSX, if you get checkpointed.
JB>
JB>The only stuff down that that do matter are things used at the user level,
JB>which you noticed. You have FCS pointers, $DSW, but I think there might also
JB>be some overlay pointers if you use that, and I can't remember what else. But
JB>stuff used by libraries that you link, essentially. TKB knows an awful lot
JB>about FCS...
JB>
JB>> The one location which is heavily used is the DSW which receives the
JB>> status of the preceding RSX system call. I don't know how RTEM manages
JB>> the DSW. If it was me, I'd probably be context switching it
JB>> before/after issuing an exec. directive on behalf of an RT-11 program,
JB>> but their may be more sophisticated ways of managing the DSW.
JB>
JB>Quite possible they just save that location. I don't really know.
JB>As for FCS, they might just not use it...
JB>
JB>Nice with the documentation. Would be nice to read it...

I wrote an RT-11 emulator for RSX-11M (should have been some 4.X version)
back around 1987/88 to run the Whitesmith C-compiler on RSX. As far as I
remember by lucky(?) co-incidence the low-mem fields used by RT-11 where
not really used by RSX. The emulator mapped RT-11 file requests to RSX
file requests so the program would see the RSX files. I could even
oct-dump the RT program, produce a MACRO-11 text from it and assemble/link
it with the emulator and got an executable that would look just like an
RSX program.

Unfortunately the code was all lost when I left university in 1991 :-(
Just though I mention that it is possible...

harti

JB> JB> Johnny
JB>
JB>

[Johnny Billquist]

Ah, that explains it. No writing back of task header to task memory
space, so problem solved. :-)

> Under RSX-11M V4 you have to edit SGNEXEC.CND to get it to process a
> section titled ";RT EMULATOR" by removing a commented jump, and add
> ".SETF $RTE" to SGNSTAND.CMD.
>
> To enable executive support for RT emulation you apparently have to
> answer affirmatively to "32A. RT-11 emulation support [Y/N]" which
> results in "A$$HDR=0 :ALTERNATE TASK HEADER SUPPORT" being included in
> RSXMC.MAC.
>
> A search of the system sources for "A$$HDR" isolates the required
> code.

Yes. Now I remember that question in 11M sysgen. Never thought much
about what that actually did, but now that I know a little more of RTEM,
it makes total sense.

>> Quite possible they just save that location. I don't really know.
>> As for FCS, they might just not use it...
>
> RTEM wouldn't use FCS, libraries or overlays. RTEM doesn't support
> native RSX-11 file systems. All they need is logical I/O to volumes or
> files formatted as RT-11 disks (except for the terminal etc.)

Right, except there is a utility bundled with RTEM, called FIP, which
gives you access to the outside RSX filesystem from RTEM.
But it could potentially still do that without using FCS. Just more work...
But for the rest of it, yes, RTEM only uses raw disks, and looking the
disk files themself up is fairly trivial to do even without FCS.

> The utility RTX that I'm sketching would access native RSX-11 file
> systems and in fact probably wouldn't support RT-11 volumes ('cos both
> would cost to much memory).

Sounds similar to FIP.SAV

>> Nice with the documentation. Would be nice to read it...
>
> All I need to do is to learn how to scan without falling asleep and
> I'll make it available.

:-)

[paramucho]

On Mon, 14 Jan 2013 12:50:15 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>>> Quite possible they just save that location. I don't really know.
>>> As for FCS, they might just not use it...
>>
>> RTEM wouldn't use FCS, libraries or overlays. RTEM doesn't support
>> native RSX-11 file systems. All they need is logical I/O to volumes or
>> files formatted as RT-11 disks (except for the terminal etc.)
>
>Right, except there is a utility bundled with RTEM, called FIP, which
>gives you access to the outside RSX filesystem from RTEM.
>But it could potentially still do that without using FCS. Just more work...
>But for the rest of it, yes, RTEM only uses raw disks, and looking the
>disk files themself up is fairly trivial to do even without FCS.
>
>> The utility RTX that I'm sketching would access native RSX-11 file
>> systems and in fact probably wouldn't support RT-11 volumes ('cos both
>> would cost to much memory).
>
>Sounds similar to FIP.SAV

It's more like the migration tool Hartmut describes, except RTX would
load an RT-11 image rather than being linked with the image
statically.

Regarding FIP, the documentation includes the error message:

?FIP-F-FCS error code: n "error text"

Which means that FIP is an RT-11 image running under RTEM which uses
FCS. And that raises a question: how did they link an RT-11 image,
presumably built by RT-11 LINK rather than RSX TKB, to the FCS
routines?

<snip>

Ian

[Johnny Billquist]

I can only guess, but I would have thought they have some interface
through RTEM to get to FCS. I can't see how you'd do it otherwise. You
can't really expect FCS code to work under RT-11, as it expects both
various data structures in various places, some of them fixed, as well
as the ability to do RSX system calls of all kind, which would not work
in RTEM.
However, having one or two "extra" system calls in RTEM, which in
reality gave access to FCS to anything running under RTEM seems pretty
straight forward. But, like I said, this is guessing...

[Jerome H. Fine]

I can only guess although access to the source code should
provide the answer if the commented source code is available.

As just an example, DEC produced a total of NINE variants
for KED, three of which had the additional code to execute
under RTS for RSTS/E which is able to accept enhanced
EMT requests that execute ONLY under RSTS/E.

These enhanced EMT requests that the RTS under RSTS/E
accepts are assembled only into the variants which have been
enhanced to run under RSTS/E and include provision for the
PPN that never appears in RT-11, only under RSTS/E.

I suspect that KED is also available to be executed directly
under RSX-11 with all of the different EMT requests that
RSX-11 requires. BUT, the executable image is so different
from the RT-11 image that the DEC developers kept the
code and executable images totally separate.

Perhaps FIP contains the enhanced EMT requests which
support running under RTEM-11 under RSX-11? This is
only a suggestion. Does anyone know if this is even possible?

Jerome Fine

[Johnny Billquist]

It's a little different with RSX compared to RT-11 and RSTS/E.
This should really be obvious, and I don't know why I have to explain
this to you, Jerome.

KED under RT-11 is written in a way that uses the RT-11 EMTs. KED
running under the RT-11 in RSTS/E will use the same EMTs as plain RT-11.
There is no difference in the fundamental model of system calls.
However, there are some additional stuff that you can use/do under the
RT-11 RTS in RSTS/E, which means it might make sense to have a slightly
modified version of KED for running under RSTS/E. It does not change
much of anything in the general code.

In contrast, EMTs under RSX are a totally different thing. You cannot
just replace or enhance EMTs of an RT-11 program, and expect it to work
under RSX. There are fundamental differences about how things work,

So, no, KED with some changed EMTs would never run under RSX. The whole
I/O model is different, as well as how you access files and so on.
You need a totally different section of code in order to make it work
under RSX.

Just as an example, looking up a file in RT-11 is an EMT, unless I
remember wrong. In RSX it's a bunch of QIO$ I/O calls, followed by
reading through the directory file that you just read. And you normally
do not do that yourself, as you normally want to access files in a
somewhat structured fashion, so you normally use the FCS library to
handle all that stuff for you.

> Perhaps FIP contains the enhanced EMT requests which
> support running under RTEM-11 under RSX-11? This is
> only a suggestion. Does anyone know if this is even possible?

I believe that was exactly what I suggested... Of course it is possible.
What would prevent you from implementing some extra system calls if you
emulate the RT-11 environment?
Exactly what those system calls then do is totally up to you.

[paramucho]

On Tue, 15 Jan 2013 22:10:19 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> Regarding FIP, the documentation includes the error message:
>>
>> ?FIP-F-FCS error code: n "error text"
>>
>> Which means that FIP is an RT-11 image running under RTEM which uses
>> FCS. And that raises a question: how did they link an RT-11 image,
>> presumably built by RT-11 LINK rather than RSX TKB, to the FCS
>> routines?
>
>I can only guess, but I would have thought they have some interface
>through RTEM to get to FCS. I can't see how you'd do it otherwise. You
>can't really expect FCS code to work under RT-11, as it expects both
>various data structures in various places, some of them fixed, as well
>as the ability to do RSX system calls of all kind, which would not work
>in RTEM.
>However, having one or two "extra" system calls in RTEM, which in
>reality gave access to FCS to anything running under RTEM seems pretty
>straight forward. But, like I said, this is guessing...

RSX system calls work under RTEM. The RSX SST system call (SVTK$) only
passes non-RSX EMTs in the range 0:376 to tasks and still treats EMT
377 as an RSX system call. Indeed, RTEM itself is nothing more than
RT-11 system code running in user space which catches RT-11 EMTs and
implements them by issuing RSX EMT 377s. That's what the sketched RTX
would do (and what Hartmut's code would have done).

It's easier to work out what's happening by testing so I did some web
scrounging. I couldn't find RTEM.TSK or FIP.SAV but I did manage to
locate JOAT.SAV on a Russian site. I ran JOAT under the RUST/XM RSX
emulator with system call trace active. You can see JOAT mix the RSX
GTSK system call with RT-11 calls (all the rest, .readw etc).

1036 .readw chan=17 buf=26742 wcnt=4005 crtn=0 blk=45
27222 gtsk buf=10434
12402 .close chan=0
12442 .settop addr=36752
22162 .rctrlo
?JOAT-U-Wrong version of RTEM-11
22272 .exit r0=0

Setting a break on that GTSK$ call I could see that the return path
includes a wrapper routine which restores the $DSW (location @#46),
which was saved before GTSK$ was issued:

16544u 12637 pop @#46 |
16550u 13700 mov @#5206,r0 |
16554u 12710 mov #1656,(r0) |
16560u 207 return |


The JOAT /M command, which passes a command to RSX-11M, has the
following system call trace:

16402 gtsk buf=4170
16402 cli dic=255 siz=7 dpb=23166 dp0=23314 dp1=60 dp2=0 dp3=0
dp4=0
status dsw=177635 (sdp)
25610 qiow (det) fun=4 mod=0 lun=0 efn=0 pri=0 isb=1754 ast=0
p1=0 p2=0 p3=0 p4=0 p5=0 p6=0
status dsw=177640 (ilu)
22044 .scca addr=0

Most of the other commands fail because JOAT expects some pointer to
be setup at @#250 (and another at @#252). All these calls involve
device or file operations, so @#250 might have some kind of FCS
linkage.

Ian

[Johnny Billquist]

On 2013-01-16 14:43, paramucho wrote:
> On Tue, 15 Jan 2013 22:10:19 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>> Regarding FIP, the documentation includes the error message:
>>>
>>> ?FIP-F-FCS error code: n "error text"
>>>
>>> Which means that FIP is an RT-11 image running under RTEM which uses
>>> FCS. And that raises a question: how did they link an RT-11 image,
>>> presumably built by RT-11 LINK rather than RSX TKB, to the FCS
>>> routines?
>>
>> I can only guess, but I would have thought they have some interface
>> through RTEM to get to FCS. I can't see how you'd do it otherwise. You
>> can't really expect FCS code to work under RT-11, as it expects both
>> various data structures in various places, some of them fixed, as well
>> as the ability to do RSX system calls of all kind, which would not work
>> in RTEM.
>> However, having one or two "extra" system calls in RTEM, which in
>> reality gave access to FCS to anything running under RTEM seems pretty
>> straight forward. But, like I said, this is guessing...
>
> RSX system calls work under RTEM. The RSX SST system call (SVTK$) only
> passes non-RSX EMTs in the range 0:376 to tasks and still treats EMT
> 377 as an RSX system call. Indeed, RTEM itself is nothing more than
> RT-11 system code running in user space which catches RT-11 EMTs and
> implements them by issuing RSX EMT 377s. That's what the sketched RTX
> would do (and what Hartmut's code would have done).

Right. And a good point. However, since much of RSX file operations are
not normally done using many system calls, but are used through a
library, as well as lots of parsing information in files, you'd either
want to have that library available in RTEM, with all the implications
about other infrastructure hanging together with that, as well, or else
have a few extra system calls, which in turn translates to calls to FCS
in RTEM instead.
As I said, I don't know how it actually is done, but I would probably go
with the latter solution if I were to implement it myself.

Johnny

[paramucho]

On Wed, 16 Jan 2013 19:59:36 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>> RSX system calls work under RTEM. The RSX SST system call (SVTK$) only
>> passes non-RSX EMTs in the range 0:376 to tasks and still treats EMT
>> 377 as an RSX system call. Indeed, RTEM itself is nothing more than
>> RT-11 system code running in user space which catches RT-11 EMTs and
>> implements them by issuing RSX EMT 377s. That's what the sketched RTX
>> would do (and what Hartmut's code would have done).
>
>Right. And a good point. However, since much of RSX file operations are
>not normally done using many system calls, but are used through a
>library, as well as lots of parsing information in files, you'd either
>want to have that library available in RTEM, with all the implications
>about other infrastructure hanging together with that, as well, or else
>have a few extra system calls, which in turn translates to calls to FCS
>in RTEM instead.
>As I said, I don't know how it actually is done, but I would probably go
>with the latter solution if I were to implement it myself.

It's quite possible that they do that using the code based RTEM.TSK
which would all be RSX code. I notice that they require PLAS support,
so they might be switching back and forth between RSX code in RTEM.TSK
and RT-11 code in RTEMFB.SYS. It's hard to know without running tests.

I have noticed that most RSX folk use FCS for file operations and I'm
sure it's the best way to do it, which is probably why I'll attempt to
handcode the operations in RTX if it moves beyond a sketch :-)

BTW I think I worked out how absolute location 250 is used. It's set
up as a protected device vector. Location @#250 is a probably an
escape pointer to get to various special services. Location @#252 has
rad50 /RTE/ which acts as an el-cheapo validation test for an RTEM
environment.


Ian

[Hartmut Brandt]

On Tue, 15 Jan 2013, paramucho wrote:

p>On Mon, 14 Jan 2013 12:50:15 +0100, Johnny Billquist <b...@softjar.se>
p>wrote:
p>
p><snip>
p>

p>>>> Quite possible they just save that location. I don't really know.

p>>>> As for FCS, they might just not use it...
p>>>
p>>> RTEM wouldn't use FCS, libraries or overlays. RTEM doesn't support
p>>> native RSX-11 file systems. All they need is logical I/O to volumes or
p>>> files formatted as RT-11 disks (except for the terminal etc.)
p>>
p>>Right, except there is a utility bundled with RTEM, called FIP, which
p>>gives you access to the outside RSX filesystem from RTEM.
p>>But it could potentially still do that without using FCS. Just more work...
p>>But for the rest of it, yes, RTEM only uses raw disks, and looking the
p>>disk files themself up is fairly trivial to do even without FCS.
p>>
p>>> The utility RTX that I'm sketching would access native RSX-11 file
p>>> systems and in fact probably wouldn't support RT-11 volumes ('cos both
p>>> would cost to much memory).
p>>
p>>Sounds similar to FIP.SAV
p>
p>It's more like the migration tool Hartmut describes, except RTX would
p>load an RT-11 image rather than being linked with the image
p>statically.
p>
p>Regarding FIP, the documentation includes the error message:
p>
p> ?FIP-F-FCS error code: n "error text"
p>
p>Which means that FIP is an RT-11 image running under RTEM which uses
p>FCS. And that raises a question: how did they link an RT-11 image,
p>presumably built by RT-11 LINK rather than RSX TKB, to the FCS
p>routines?

Maybe I don't understand the question correctly, but here is what I did:
you set up to catch all the EMTs (there is an RSX directive to do that).
That actually gives you only EMTs up to 376. 377 will be routed to RSX
anyway. Then you translate all the file-related EMTs from their RT
semantics to RSX semantics and do the right calls into FCS. Given that
there is no 1:1 relation between RT and FCS file operations this is
sometimes tricky, but in my case (getting a compiler to run) it was mostly
straightforward.

So, in your RSX RT-emulator you set up everything, read the RT-11 program
into the right spot in memory (you must link the RSX program in a way that
the addresses usually occupied by RT programs are free) and just execute
it. As the RT program is calling its system by executing EMTs the emulator
will get them, translate them and do the right things (hopefully). This
works, of course, only with RT programs that don't try to reach into the
operating system directly...

harti

[Johnny Billquist]

What you describe is perfectly valid, Harti.
However, you need to dig deeper. Once you have your RT-11 environment,
then what? You will be able to run RT-11 programs. So you have MACRO-11
for RT-11, the LINKER, and all other tools just as any standard RT-11
environment have. You can then write additional RT-11 programs, even
though this is actually an emulated RT-11 environment running under RSX.
But let's now assume that you write a program under RT-11, which in fact
would like to access files outside of the RT-11 environment, and
actually read a file from the host RSX environment.
This is the problem talked about.

You could do this in atleast two ways.
1) Use the RSX EMT to do I/O. However, since most parts of file
operations in RSX is done by a library and not by system calls, this
means you need to get the whole RSX file I/O library ported over to
RT-11, in order to use this properly. (And with "ported" I mean
compiled, linked and put in a library, as well as getting all the macro
definitions from RSX over.)
2) Create some new system calls, that your RT-11 program can use to read
files from the RSX environment. Your emulator would then catch those
calls as well, and do the appropriate work for you, and perform the I/O,
though the RSX libraries, inside the emulator.

Johnny

[paramucho]

On Tue, 22 Jan 2013 10:53:29 +0100, Hartmut Brandt <bran...@dlr.de>
wrote:

>p>Which means that FIP is an RT-11 image running under RTEM which uses
>p>FCS. And that raises a question: how did they link an RT-11 image,
>p>presumably built by RT-11 LINK rather than RSX TKB, to the FCS
>p>routines?
>
>Maybe I don't understand the question correctly, but here is what I did:
>you set up to catch all the EMTs (there is an RSX directive to do that).
>That actually gives you only EMTs up to 376. 377 will be routed to RSX
>anyway. Then you translate all the file-related EMTs from their RT
>semantics to RSX semantics and do the right calls into FCS. Given that
>there is no 1:1 relation between RT and FCS file operations this is
>sometimes tricky, but in my case (getting a compiler to run) it was mostly
>straightforward.
>
>So, in your RSX RT-emulator you set up everything, read the RT-11 program
>into the right spot in memory (you must link the RSX program in a way that
>the addresses usually occupied by RT programs are free) and just execute
>it. As the RT program is calling its system by executing EMTs the emulator
>will get them, translate them and do the right things (hopefully). This
>works, of course, only with RT programs that don't try to reach into the
>operating system directly...

That's right. I wrote an RT-11 "AME" (Application Migration Executive)
for VAX/VMS, similar to the RSX AME, which worked that way. After the
image is loaded it's just a matter of translating system calls, and
that's quite easy to do for *most* programs and *most* calls.

The tricky bit, for RT-11 to RSX or VMS, is not the translation of the
system call interface but rather the file systems. Many RT-11 programs
rely on RT-11's tentative file behaviour where a new file does not
appear in a directory until the file is closed. A full translation of
all the details of the RT-11 file system to RSX or VMS requires much
more code than the O/S interface.

Programs like the RT-11 linker use the RT-11 .SAVESTATUS/.REOPEN
heavily to access files. That can require caching channel information
to fully resolve.

I first wrote software to solve these problems for a transparent
network that allowed RT-11 or RUST uses to treat remote VMS (or RUST)
devices as if they were local. More recently I redid interfaces to
support RUST to Windows file system translation which I use for the
RUST network and Windows emulator.

C programs have a fairly well-defined work flow which translates
fairly easily to most systems (although that's not true for the
original Unix applications where many have there own unique tricks
when creating and working with temporary files).

Ian

[paramucho]

On Tue, 22 Jan 2013 14:52:41 +0100, Johnny Billquist <b...@softjar.se>
wrote:

From what he says, I think Harti did access local native RSX files.

The first option you outline is how I implemented RT-11 emulator I did
for VAX/VMS because I had all the room in the world. Directory
operations were translated into RMS calls and I used QIO for a lot of
the read/write. The translation code I now use with Windows uses
essentially the same work flow. As I noted, it's the translation of
file system semantics that takes up a lot more development time and a
lot more space. It can get quite tricky.

I guess that RTEM.TSK uses this approach. RTEM.TSK would be a standard
RSX image linked to FCP. It could use PLAS calls to map the emulated
RT-11 image and monitor. It could translate RT-11 I/O by packaging up
the system call data in some high memory buffer and then remapping the
RSX code to handle the operation using FCP.


The second option, adding new calls, would defeat the original purpose
of emulation if apps had to use the new calls.


There is a third option. A simple RT-11 emulator really only needs to
open a very small number of record formats. RT-11 programs don't use
any of the RSX record formats except block I/O for disk-like devices
and character I/O to terminals. FCP is not required to manage this
simple kind of I/O. It can all be done with QIO.

Directory searchs require that host directories need to be translated
into RT-11 directory structures. I do that with Windows directories,
and it's pretty straight-forward. It would take longer with RSX
because you'd have to read the index files to get the creation date
info etc.

It's not hard to work out what FCP does if you use a system trace.
Here's an excerpt from RSX PIP.TSK running under the RUST/XM RSX
emulator running under V11 on Windows (in this case RSX system calls
are translated into RT-11/RUST calls).

!
! PIP finds RUST.COM
!
26456 alun lun=3 dev=SY:
26620 glun lun=3 buf=15370
20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
fid=. nam=001004.dir;1 sta=0 nxt=0
did=dd.ft dev=SY:
26456 alun lun=3 dev=SY:
26620 glun lun=3 buf=15370
20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
fid=. nam=rust.com;0 sta=100006 nxt=0
did=001004.dir dev=SY:
30556k .purge chan=1
30620k .lookup chan=1 dblk=54052=sy:rust.com (eve) seq=0
22776k .readw chan=1 buf=70106 wcnt=1000 crtn=0 blk=12
22776k .readw chan=1 buf=66054 wcnt=1000 crtn=0 blk=14
22776k .readw chan=1 buf=64022 wcnt=1000 crtn=0 blk=16
34740 qio (rat) fun=26 mod=0 lun=3 efn=2 pri=0 isb=1724 ast=0
p1=1654 p2=3600 p3=0 p4=0 p5=0 p6=0
fid=rust.com
34754 wtse efn=2
!
! PIP opens RUST.COM using ACR
!
26456 alun lun=3 dev=SY:
26620 glun lun=3 buf=15370
20426 qiow (acr) fun=15 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
p1=1654 p2=334 p3=0 p4=0 p5=100400 p6=0
fid=rust.com
20426 qiow (rvb) fun=21 mod=0 lun=3 efn=40 pri=0 isb=36620 ast=0
p1=36640 p2=1000 p3=0 p4=0 p5=1 p6=0
25770k .io chan=1 func=(102,0) buf=36640 wcnt=400 blk=0 crtn=0
status dsw=1 (suc) ios=1 trm=0 (suc) val=1000

The full trace, including the translation to RT-11 system calls, is
available at http://code.google.com/p/rust/downloads/list as PIP.TXT.


Ian

[Johnny Billquist]

I don't think there was any question about that part... :-)

> The first option you outline is how I implemented RT-11 emulator I did
> for VAX/VMS because I had all the room in the world. Directory
> operations were translated into RMS calls and I used QIO for a lot of
> the read/write. The translation code I now use with Windows uses
> essentially the same work flow. As I noted, it's the translation of
> file system semantics that takes up a lot more development time and a
> lot more space. It can get quite tricky.

I don't recall exactly how things look in VMS. There are sometimes small
differences to RSX, so I prefer to keep it to RSX here for simple reasons...

It is not that you couldn't just do the QIO from your RT-11 program.
Sure you could. However, that would leave you with a lot of
post-processing to be done in the RT-11 program, which would have to be
aware of RSX file structures and what not.

"Directory" operations in RSX are rather simplistic. You can search the
directory, enter and delete entries, and that is about it. In order to
locate a file, you first need to search the MFD, looking for either your
file, or your directory. And then do another search in your directory,
for your file. In case you have several levels of directories, this is a
rather iterative process.

And everything after that point deals with file ids, which you use for
all manipulations of the file. And of course, you then have the LUN,
which you use for all operations on an open file.

And all of these steps are done using QIO in RSX. Or else you can call a
library routine in FCS or RMS, which does all those QIOs for you, along
with a lot of interpretations of data in between.

However, if you don't add any new services at the emulator level, then
you instead have to understand RSX files and file structures at the
application level.

> I guess that RTEM.TSK uses this approach. RTEM.TSK would be a standard
> RSX image linked to FCP. It could use PLAS calls to map the emulated
> RT-11 image and monitor. It could translate RT-11 I/O by packaging up
> the system call data in some high memory buffer and then remapping the
> RSX code to handle the operation using FCP.

What is FCP? It's not a component of RSX. Are you in fact meaning FCS?
If so, this would exactly describe my second option.
The first option implies linking FCS into all the RT-11 images running
under RTEM.

> The second option, adding new calls, would defeat the original purpose
> of emulation if apps had to use the new calls.

The RSX file system is not available natively in either case, so I fail
to see your point (ie. any generic RT-11 program running under RTEM
cannot access the RSX file system).

You have a special program (FIP.SAV in this case), which can access the
RSX file system. FIP.SAV can either do that by having a copy of FCS, and
do the RSX QIOs. There are some additional headaches with this, since
FCS expects, and uses some fixed areas in your memory for its
structures, which might very well conflict with RT-11. The other option
is to have FIP use system calls that goes down to RTEM, which then
performs services for FIP, such as file access operations. In this case,
the file operations, as well as translation of semantics, data
structures, and everything else, is code in RTEM, which is already an
RSX task, linked to FCS.

Of course, apart from the file operations provided by the QIO interface,
all disk blocks read in must also be massaged, as the actual file
content structure in RSX is very different from RT-11. RSX have these
records, which can be of various lengths, span physical blocks, have
format information embedded, and so on...
You cannot feed that directory to an RT-11 program and expect anything
meaningful to come out of it.

> There is a third option. A simple RT-11 emulator really only needs to
> open a very small number of record formats. RT-11 programs don't use
> any of the RSX record formats except block I/O for disk-like devices
> and character I/O to terminals. FCP is not required to manage this
> simple kind of I/O. It can all be done with QIO.

That kind of approach would not even let you read a normal text file
from RSX into RT-11.

> Directory searchs require that host directories need to be translated
> into RT-11 directory structures. I do that with Windows directories,
> and it's pretty straight-forward. It would take longer with RSX
> because you'd have to read the index files to get the creation date
> info etc.

You don't do that by reading the directory file or INDEXF.SYS. That is
done by QIO functions to the F11ACP.

> It's not hard to work out what FCP does if you use a system trace.
> Here's an excerpt from RSX PIP.TSK running under the RUST/XM RSX
> emulator running under V11 on Windows (in this case RSX system calls
> are translated into RT-11/RUST calls).
>
> !
> ! PIP finds RUST.COM
> !
> 26456 alun lun=3 dev=SY:
> 26620 glun lun=3 buf=15370
> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
> fid=. nam=001004.dir;1 sta=0 nxt=0
> did=dd.ft dev=SY:

This is locating the UFD in the MFD. Your presentation of the DID is
weird. The DID is a a file id. Essentially three 16-bit numbers, which
tells in which file to search for the other file, given by the NAM field.

And the MFD is, by the way, always FID (4,4,0). (And FID and DID is the
same type of information, just two different fields.)

P6 points to a FNAM structure, which I'm sure you know...

> 26456 alun lun=3 dev=SY:
> 26620 glun lun=3 buf=15370
> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
> fid=. nam=rust.com;0 sta=100006 nxt=0
> did=001004.dir dev=SY:

Did you do a translation of the DID into a file name here? Because the
DID here should just be the resulting FID from the previous IO.FNA you
have above.

Same story as above otherwise. And this could in theory be repeated
additional times, if you had a hierarchical directory structure.

> 30556k .purge chan=1
> 30620k .lookup chan=1 dblk=54052=sy:rust.com (eve) seq=0
> 22776k .readw chan=1 buf=70106 wcnt=1000 crtn=0 blk=12
> 22776k .readw chan=1 buf=66054 wcnt=1000 crtn=0 blk=14
> 22776k .readw chan=1 buf=64022 wcnt=1000 crtn=0 blk=16

This looks very RT-11is to me. :-)

> 34740 qio (rat) fun=26 mod=0 lun=3 efn=2 pri=0 isb=1724 ast=0
> p1=1654 p2=3600 p3=0 p4=0 p5=0 p6=0
> fid=rust.com

This is reading some metadata from the file. However, based on the event
flag, this is not done by FCS, but the application program itself.
Could be anything from record type, record attributes, record length,
file dates, file size, owner, or something else...

> 34754 wtse efn=2

And obviously just waiting for it to complete. Silly code. Why not a
QIOW in this case?

> !
> ! PIP opens RUST.COM using ACR
> !
> 26456 alun lun=3 dev=SY:
> 26620 glun lun=3 buf=15370
> 20426 qiow (acr) fun=15 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
> p1=1654 p2=334 p3=0 p4=0 p5=100400 p6=0
> fid=rust.com

Access the file for read.

> 20426 qiow (rvb) fun=21 mod=0 lun=3 efn=40 pri=0 isb=36620 ast=0
> p1=36640 p2=1000 p3=0 p4=0 p5=1 p6=0

And read the first block. (P1 -> Address to place data, P2 = Size, P5,P6
is block number)

For something like a text file, FCS will, after this, start handing out
data to the program from the FCS-internal disk buffer, one record at a
time. And when the first block is exhausted, FCS will read in the next
one, and continue.

Johnny

[paramucho]

On Wed, 23 Jan 2013 20:53:58 +0100, Johnny Billquist <b...@softjar.se>
wrote:

I should have pointed out that the simple emulator I'm sketching at
the moment would not attempt to translate between RT-11 file
structures and RSX file and record structures. That's a different
task, and substantially more complex.

The only way that that RT-11 programs running in the emulator could
work with native RSX file and record structures would be if they were
identical in the first place, or if an external conversion process
took place.

Now, if ask: "if you can't deal with RSX data, then what's the point?"
The answer to that is: "That's one good reason I haven't actually
written such an emulator over the past 30 years." But there are
programs that don't need data, and sometimes the data is compatible,
and sometimes conversion isn't difficult.

But mostly the reason for me now sketching RTX.TSK is because
sometimes it would just be nice to be able to test something out under
RSX without having to think about rewriting it (which I never do).
That was the case with a little app called GRUB.SAV I wrote a few
weeks ago. I would have liked to have tested it under RSX, but the
thought of dealing with all the stuff I don't quite get in RSX makes
me feel like I've got my thumbs tied together.

In fact, I wrote exactly this kind of emulator for VAX/VMS, called
VRT, except that VRT ran a fully compatible RT-11/SJ system rather
than just an image level emulator (I don't have the space for that in
RSX). I found it really handy--I used to patch VMS directories with it
when they broke. On the other hand, I think we only ever sold two
copies of the thing.

>> I guess that RTEM.TSK uses this approach. RTEM.TSK would be a standard
>> RSX image linked to FCP. It could use PLAS calls to map the emulated
>> RT-11 image and monitor. It could translate RT-11 I/O by packaging up
>> the system call data in some high memory buffer and then remapping the
>> RSX code to handle the operation using FCP.
>
>What is FCP? It's not a component of RSX. Are you in fact meaning FCS?
>If so, this would exactly describe my second option.
>The first option implies linking FCS into all the RT-11 images running
>under RTEM.

So much for my huge knowledge of RSX--FCS.

I was looking for FCS source, and ended up looking at FCP source code,
which then rewired my tiny brain.

>> The second option, adding new calls, would defeat the original purpose
>> of emulation if apps had to use the new calls.
>
>The RSX file system is not available natively in either case, so I fail
>to see your point (ie. any generic RT-11 program running under RTEM
>cannot access the RSX file system).

I'm not sure what you mean. My sketched emulator wouldn't have
anything to do with RTEM at all.

RTX.TSK would be a new RSX program and be a fully self-contained RT-11
emulator. As is the case with RT-11, all the system code would be in
high memory. Low memory space would be used by the RT-11 app. There
would be no emulated RSX disk.

>You have a special program (FIP.SAV in this case), which can access the
>RSX file system. FIP.SAV can either do that by having a copy of FCS, and
>do the RSX QIOs. There are some additional headaches with this, since
>FCS expects, and uses some fixed areas in your memory for its
>structures, which might very well conflict with RT-11. The other option
>is to have FIP use system calls that goes down to RTEM, which then
>performs services for FIP, such as file access operations. In this case,
>the file operations, as well as translation of semantics, data
>structures, and everything else, is code in RTEM, which is already an
>RSX task, linked to FCS.

As you say, FIP is a a special case which is specifically written to
handle both file and record systems in some manner. There may well be
hidden little trap doors in the emulated workspace to call RTEM.TSK to
handle FCS. I've already noted device vector @#250 providing some kind
of entry point. Testing with something like a system call trace is
required to answer this kind of question, although an intelligent
PDP-11 instruction dump of FIP would also provide a number of clues.
(and DUMP.SAV is an example of a program which could be used
meaningfully in RTX.TSK).

>Of course, apart from the file operations provided by the QIO interface,
>all disk blocks read in must also be massaged, as the actual file
>content structure in RSX is very different from RT-11. RSX have these
>records, which can be of various lengths, span physical blocks, have
>format information embedded, and so on...
>You cannot feed that directory to an RT-11 program and expect anything
>meaningful to come out of it.

Once again, I'm not planning to record-level translation in this
emulator. RT-11 programs would use RT-11 data, or files which are
compatible by chance, or a conversion process would be necessary.

I'm never quite sure whether RSX supports stream files. If it did then
it might be possible to share text files in that manner.

>> There is a third option. A simple RT-11 emulator really only needs to
>> open a very small number of record formats. RT-11 programs don't use
>> any of the RSX record formats except block I/O for disk-like devices
>> and character I/O to terminals. FCP is not required to manage this
>> simple kind of I/O. It can all be done with QIO.
>
>That kind of approach would not even let you read a normal text file
>from RSX into RT-11.

See the point above.

>> Directory searchs require that host directories need to be translated
>> into RT-11 directory structures. I do that with Windows directories,
>> and it's pretty straight-forward. It would take longer with RSX
>> because you'd have to read the index files to get the creation date
>> info etc.
>
>You don't do that by reading the directory file or INDEXF.SYS. That is
>done by QIO functions to the F11ACP.

Sorry, poor RSX terminology again, I meant the file headers, and I
confess I haven't looked at how you do that under RSX because I used
RMS to do it under VAX/VMS. It wouldn't be a high priority for a first
version of RTX.TSK.

>> It's not hard to work out what FCP does if you use a system trace.
>> Here's an excerpt from RSX PIP.TSK running under the RUST/XM RSX
>> emulator running under V11 on Windows (in this case RSX system calls
>> are translated into RT-11/RUST calls).
>>
>> !
>> ! PIP finds RUST.COM
>> !
>> 26456 alun lun=3 dev=SY:
>> 26620 glun lun=3 buf=15370
>> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
>> fid=. nam=001004.dir;1 sta=0 nxt=0
>> did=dd.ft dev=SY:
>
>This is locating the UFD in the MFD. Your presentation of the DID is
>weird. The DID is a a file id. Essentially three 16-bit numbers, which
>tells in which file to search for the other file, given by the NAM field.
>
>And the MFD is, by the way, always FID (4,4,0). (And FID and DID is the
>same type of information, just two different fields.)

This code is running under an RSX emulator running under RUST/XM, so I
translate some info to be more meaningful in that environment.

I do have a system trace for raw RSX in V11, but it provides much less
info.

>P6 points to a FNAM structure, which I'm sure you know...
>
>> 26456 alun lun=3 dev=SY:
>> 26620 glun lun=3 buf=15370
>> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
>> fid=. nam=rust.com;0 sta=100006 nxt=0
>> did=001004.dir dev=SY:
>
>Did you do a translation of the DID into a file name here? Because the
>DID here should just be the resulting FID from the previous IO.FNA you
>have above.
>
>Same story as above otherwise. And this could in theory be repeated
>additional times, if you had a hierarchical directory structure.

Yes, the trace it's reporting a world that exists somewhere between
the RSX app and the RUST operating system. There is no RSX file
structure available in RUST. RSX programs run out of RT-11 directories
and use files in RSX directories. I fudge the record-level
descriptors, based on file types. But that's a whole different story.

>> 30556k .purge chan=1
>> 30620k .lookup chan=1 dblk=54052=sy:rust.com (eve) seq=0
>> 22776k .readw chan=1 buf=70106 wcnt=1000 crtn=0 blk=12
>> 22776k .readw chan=1 buf=66054 wcnt=1000 crtn=0 blk=14
>> 22776k .readw chan=1 buf=64022 wcnt=1000 crtn=0 blk=16
>
>This looks very RT-11is to me. :-)

Yes, this is the emulator issuing the appropriate RT-11 emts to
implement the RSX "fna" QIO function. The "k" at the end of the
address in the left column means it's operating in kernel space
(which is where the RSX emulator lives).

There were man more RT-11 calls originally which I edited out. I
missed this bit. All the gory details are in the listing file PIP.TXT
at http://code.google.com/p/rust/downloads/list

>> 34740 qio (rat) fun=26 mod=0 lun=3 efn=2 pri=0 isb=1724 ast=0
>> p1=1654 p2=3600 p3=0 p4=0 p5=0 p6=0
>> fid=rust.com
>
>This is reading some metadata from the file. However, based on the event
>flag, this is not done by FCS, but the application program itself.
>Could be anything from record type, record attributes, record length,
>file dates, file size, owner, or something else...

The execution address, 34740, seems to be higher than most of the FCS
code in PIP.TXT. Another way to check would be to perform the same
kind of operation with a different RSX utility and see whether the
same call was issued.

>> 34754 wtse efn=2
>
>And obviously just waiting for it to complete. Silly code. Why not a
>QIOW in this case?

That's what happens when people write library code and then spend a
decade altering it. It becomes a mess of conditionals and noisey,
incomprehensible jibber jabber...

>> !
>> ! PIP opens RUST.COM using ACR
>> !
>> 26456 alun lun=3 dev=SY:
>> 26620 glun lun=3 buf=15370
>> 20426 qiow (acr) fun=15 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>> p1=1654 p2=334 p3=0 p4=0 p5=100400 p6=0
>> fid=rust.com
>
>Access the file for read.
>
>> 20426 qiow (rvb) fun=21 mod=0 lun=3 efn=40 pri=0 isb=36620 ast=0
>> p1=36640 p2=1000 p3=0 p4=0 p5=1 p6=0
>
>And read the first block. (P1 -> Address to place data, P2 = Size, P5,P6
>is block number)
>
>For something like a text file, FCS will, after this, start handing out
>data to the program from the FCS-internal disk buffer, one record at a
>time. And when the first block is exhausted, FCS will read in the next
>one, and continue.

As above, record-level translation is a separate issue.

All RT-11 programs do their own record operations. RT-11 does not
provide any system-level file-to-record functionality. RT-11 I/O is
restricted to the equivalent of RSX virtual/logical block I/O. That's
it.

Now, it wouldn't be too hard to feed the input from a variable length
RSX text file to an RT-11 program as a stream file, just so long as
the access is strictly sequential--and that's usually the case.
Likewise for output.

But, it starts taking a lot of space when you have to deal with
multiple files, and it gets really icky if a program detaches a file
and later reattaches and keeps going from where it left off.

Then you have things like MACRO libraries which have mixed record
types.

All that said, in the example above PIP.TSK happily sends the RT-11
file RUST.COM to the terminal in a coherent way. But that's the
exception.

Ian

[Johnny Billquist]

I'll strip the rest of this subject, and just make this comment:
Aha. I see. Well, sure, that is certainly doable, and a lot easier. Not
that your files will be very useful under RSX, but you already know that.

> The only way that that RT-11 programs running in the emulator could
> work with native RSX file and record structures would be if they were
> identical in the first place, or if an external conversion process
> took place.

Right.

>>> I guess that RTEM.TSK uses this approach. RTEM.TSK would be a standard
>>> RSX image linked to FCP. It could use PLAS calls to map the emulated
>>> RT-11 image and monitor. It could translate RT-11 I/O by packaging up
>>> the system call data in some high memory buffer and then remapping the
>>> RSX code to handle the operation using FCP.
>>
>> What is FCP? It's not a component of RSX. Are you in fact meaning FCS?
>> If so, this would exactly describe my second option.
>> The first option implies linking FCS into all the RT-11 images running
>> under RTEM.
>
> So much for my huge knowledge of RSX--FCS.

:-)

> I was looking for FCS source, and ended up looking at FCP source code,
> which then rewired my tiny brain.

LB:[50,10] should be where you find FCS sources, unless my brain fails me.

>>> The second option, adding new calls, would defeat the original purpose
>>> of emulation if apps had to use the new calls.
>>
>> The RSX file system is not available natively in either case, so I fail
>> to see your point (ie. any generic RT-11 program running under RTEM
>> cannot access the RSX file system).
>
> I'm not sure what you mean. My sketched emulator wouldn't have
> anything to do with RTEM at all.

I guess a confusion between us. I came here from Hartmut's comments on
doing RSX I/O from RT-11 and asking what he missed, and I expanded on
this in the context of RTEM, which have a utility called FIP, which do
allow access to RSX files from RT-11, and that obviously it must do it
in one of the two ways I've mentioned.

>> You have a special program (FIP.SAV in this case), which can access the
>> RSX file system. FIP.SAV can either do that by having a copy of FCS, and
>> do the RSX QIOs. There are some additional headaches with this, since
>> FCS expects, and uses some fixed areas in your memory for its
>> structures, which might very well conflict with RT-11. The other option
>> is to have FIP use system calls that goes down to RTEM, which then
>> performs services for FIP, such as file access operations. In this case,
>> the file operations, as well as translation of semantics, data
>> structures, and everything else, is code in RTEM, which is already an
>> RSX task, linked to FCS.
>
> As you say, FIP is a a special case which is specifically written to
> handle both file and record systems in some manner. There may well be
> hidden little trap doors in the emulated workspace to call RTEM.TSK to
> handle FCS. I've already noted device vector @#250 providing some kind
> of entry point. Testing with something like a system call trace is
> required to answer this kind of question, although an intelligent
> PDP-11 instruction dump of FIP would also provide a number of clues.
> (and DUMP.SAV is an example of a program which could be used
> meaningfully in RTX.TSK).

Well, since FIP is an RT-11 program to start with, why not run DUMP.SAV
directly, and look at it?

> I'm never quite sure whether RSX supports stream files. If it did then
> it might be possible to share text files in that manner.

The answer is somewhat complex. Let's just say that it don't.
To be a bit more specific, FCS don't, but RMS do. But almost no tools or
system utilities use RMS to start with, so it's a support used extremely
little.

>>> Directory searchs require that host directories need to be translated
>>> into RT-11 directory structures. I do that with Windows directories,
>>> and it's pretty straight-forward. It would take longer with RSX
>>> because you'd have to read the index files to get the creation date
>>> info etc.
>>
>> You don't do that by reading the directory file or INDEXF.SYS. That is
>> done by QIO functions to the F11ACP.
>
> Sorry, poor RSX terminology again, I meant the file headers, and I
> confess I haven't looked at how you do that under RSX because I used
> RMS to do it under VAX/VMS. It wouldn't be a high priority for a first
> version of RTX.TSK.

The file header is actually located in INDEXF.SYS. But the way to read
that information is through QIO. That is what IO.RAT and IO.WAT does.
(Read/Write attributes)
The directory file as such only holds the file name, and file id.
Nothing more. It's just a simple mapping from name to FID.

>>> It's not hard to work out what FCP does if you use a system trace.
>>> Here's an excerpt from RSX PIP.TSK running under the RUST/XM RSX
>>> emulator running under V11 on Windows (in this case RSX system calls
>>> are translated into RT-11/RUST calls).
>>>
>>> !
>>> ! PIP finds RUST.COM
>>> !
>>> 26456 alun lun=3 dev=SY:
>>> 26620 glun lun=3 buf=15370
>>> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>>> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
>>> fid=. nam=001004.dir;1 sta=0 nxt=0
>>> did=dd.ft dev=SY:
>>
>> This is locating the UFD in the MFD. Your presentation of the DID is
>> weird. The DID is a a file id. Essentially three 16-bit numbers, which
>> tells in which file to search for the other file, given by the NAM field.
>>
>> And the MFD is, by the way, always FID (4,4,0). (And FID and DID is the
>> same type of information, just two different fields.)
>
> This code is running under an RSX emulator running under RUST/XM, so I
> translate some info to be more meaningful in that environment.

Ok. Just to make it clear. The DID should be better represented as
(4,4,0) here, or possibly (if you want to try to be fancy, but
potentially incorrect) "000000.DIR".

>> P6 points to a FNAM structure, which I'm sure you know...
>>
>>> 26456 alun lun=3 dev=SY:
>>> 26620 glun lun=3 buf=15370
>>> 20426 qiow (fna) fun=11 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>>> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
>>> fid=. nam=rust.com;0 sta=100006 nxt=0
>>> did=001004.dir dev=SY:
>>
>> Did you do a translation of the DID into a file name here? Because the
>> DID here should just be the resulting FID from the previous IO.FNA you
>> have above.
>>
>> Same story as above otherwise. And this could in theory be repeated
>> additional times, if you had a hierarchical directory structure.
>
> Yes, the trace it's reporting a world that exists somewhere between
> the RSX app and the RUST operating system. There is no RSX file
> structure available in RUST. RSX programs run out of RT-11 directories
> and use files in RSX directories. I fudge the record-level
> descriptors, based on file types. But that's a whole different story.

Aha. So IO.FNA in RUST pretty much ignores the DID field then, I assume?

>>> 34740 qio (rat) fun=26 mod=0 lun=3 efn=2 pri=0 isb=1724 ast=0
>>> p1=1654 p2=3600 p3=0 p4=0 p5=0 p6=0
>>> fid=rust.com
>>
>> This is reading some metadata from the file. However, based on the event
>> flag, this is not done by FCS, but the application program itself.
>> Could be anything from record type, record attributes, record length,
>> file dates, file size, owner, or something else...
>
> The execution address, 34740, seems to be higher than most of the FCS
> code in PIP.TXT. Another way to check would be to perform the same
> kind of operation with a different RSX utility and see whether the
> same call was issued.

I'd say that the EFN pretty much already gives it away. FCS only uses
one EFN, and that was 40, as shown earlier. (40 being the default, but
you can get it to use another if you want to.)
Different files can (of course) also use different EFNs, but you
normally don't.

>>> 34754 wtse efn=2
>>
>> And obviously just waiting for it to complete. Silly code. Why not a
>> QIOW in this case?
>
> That's what happens when people write library code and then spend a
> decade altering it. It becomes a mess of conditionals and noisey,
> incomprehensible jibber jabber...

:-)

>>> !
>>> ! PIP opens RUST.COM using ACR
>>> !
>>> 26456 alun lun=3 dev=SY:
>>> 26620 glun lun=3 buf=15370
>>> 20426 qiow (acr) fun=15 mod=0 lun=3 efn=40 pri=0 isb=15420 ast=0
>>> p1=1654 p2=334 p3=0 p4=0 p5=100400 p6=0
>>> fid=rust.com
>>
>> Access the file for read.
>>
>>> 20426 qiow (rvb) fun=21 mod=0 lun=3 efn=40 pri=0 isb=36620 ast=0
>>> p1=36640 p2=1000 p3=0 p4=0 p5=1 p6=0
>>
>> And read the first block. (P1 -> Address to place data, P2 = Size, P5,P6
>> is block number)
>>
>> For something like a text file, FCS will, after this, start handing out
>> data to the program from the FCS-internal disk buffer, one record at a
>> time. And when the first block is exhausted, FCS will read in the next
>> one, and continue.
>
> As above, record-level translation is a separate issue.
>
> All RT-11 programs do their own record operations. RT-11 does not
> provide any system-level file-to-record functionality. RT-11 I/O is
> restricted to the equivalent of RSX virtual/logical block I/O. That's
> it.

Right.

> Now, it wouldn't be too hard to feed the input from a variable length
> RSX text file to an RT-11 program as a stream file, just so long as
> the access is strictly sequential--and that's usually the case.
> Likewise for output.

Yup. But you'd need to do the blocking/deblocking somewhere.

> But, it starts taking a lot of space when you have to deal with
> multiple files, and it gets really icky if a program detaches a file
> and later reattaches and keeps going from where it left off.

Yes.

> Then you have things like MACRO libraries which have mixed record
> types.
>
> All that said, in the example above PIP.TSK happily sends the RT-11
> file RUST.COM to the terminal in a coherent way. But that's the
> exception.

Hmm. What do you return back for the IO.RAT function in RUST?

[paramucho]

On Sat, 26 Jan 2013 00:39:04 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> I should have pointed out that the simple emulator I'm sketching at
>> the moment would not attempt to translate between RT-11 file
>> structures and RSX file and record structures. That's a different
>> task, and substantially more complex.
>
>I'll strip the rest of this subject, and just make this comment:
>Aha. I see. Well, sure, that is certainly doable, and a lot easier. Not
>that your files will be very useful under RSX, but you already know that.

Er, well, hmm, sure, yikes, I guess...

>> I was looking for FCS source, and ended up looking at FCP source code,
>> which then rewired my tiny brain.
>
>LB:[50,10] should be where you find FCS sources, unless my brain fails me.

Thanks--at present I don't have an RSX volume with that directory
present, but there's a whole lot more zip files to check out.

>> As you say, FIP is a a special case which is specifically written to
>> handle both file and record systems in some manner. There may well be
>> hidden little trap doors in the emulated workspace to call RTEM.TSK to
>> handle FCS. I've already noted device vector @#250 providing some kind
>> of entry point. Testing with something like a system call trace is
>> required to answer this kind of question, although an intelligent
>> PDP-11 instruction dump of FIP would also provide a number of clues.
>> (and DUMP.SAV is an example of a program which could be used
>> meaningfully in RTX.TSK).
>
>Well, since FIP is an RT-11 program to start with, why not run DUMP.SAV
>directly, and look at it?

I don't have an RTEM kit or FIP. I'd run tests on all of it if I did.
All I've managed to find on the web is a copy of JOAT.SAV.

>> I'm never quite sure whether RSX supports stream files. If it did then
>> it might be possible to share text files in that manner.
>
>The answer is somewhat complex. Let's just say that it don't.
>To be a bit more specific, FCS don't, but RMS do. But almost no tools or
>system utilities use RMS to start with, so it's a support used extremely
>little.

I thought it was a bit like that, but I was looking through some
library modules for DECUS-C a few days ago and they talked about RSX
stream file support and some patch which was required for VMS. I
didn't go into the detail at the time.

<snip>

>> Sorry, poor RSX terminology again, I meant the file headers, and I
>> confess I haven't looked at how you do that under RSX because I used
>> RMS to do it under VAX/VMS. It wouldn't be a high priority for a first
>> version of RTX.TSK.
>
>The file header is actually located in INDEXF.SYS. But the way to read
>that information is through QIO. That is what IO.RAT and IO.WAT does.
>(Read/Write attributes)
>The directory file as such only holds the file name, and file id.
>Nothing more. It's just a simple mapping from name to FID.

So that's why I remember INDEXF.SYS. I did a lot of work on this for
the VMS network and AME many years ago and sort-of half remember it
from then.

>> This code is running under an RSX emulator running under RUST/XM, so I
>> translate some info to be more meaningful in that environment.
>
>Ok. Just to make it clear. The DID should be better represented as
>(4,4,0) here, or possibly (if you want to try to be fancy, but
>potentially incorrect) "000000.DIR".

<snip>

>> Yes, the trace it's reporting a world that exists somewhere between
>> the RSX app and the RUST operating system. There is no RSX file
>> structure available in RUST. RSX programs run out of RT-11 directories
>> and use files in RSX directories. I fudge the record-level
>> descriptors, based on file types. But that's a whole different story.
>
>Aha. So IO.FNA in RUST pretty much ignores the DID field then, I assume?

Yep.

RT-11 directories are single-directory devices on RT-11 and RUST/XM. I
have sub-directory support on RUST/SJ and when I finally port that to
RUST/XM I'll probably use the DID for something meaningful.

<snip>

>> Then you have things like MACRO libraries which have mixed record
>> types.
>>
>> All that said, in the example above PIP.TSK happily sends the RT-11
>> file RUST.COM to the terminal in a coherent way. But that's the
>> exception.
>
>Hmm. What do you return back for the IO.RAT function in RUST?

That is the right question. I fudge it according to the file type
using the following table. I forget how the table works, or if it
really works all that well. I guess STM is experimental.

...=0
ft...$=0
meta <entry c d e f g><.rad50 "c"><.byte ft'd'.,ft'e'$><.word f,g>

r$sftt::;type typ atr rsize maxrec
entry tmp var ccr 512. 0
;
entry doc var ccr 512. 0
entry cmd var ccr 512. 0
entry mac var ccr 512. 0
entry for var ccr 512. 0
entry ftn var ccr 512. 0
entry pas var ccr 512. 0
entry edt var ccr 512. 0
entry odl var ccr 512. 0
entry rno var ccr 512. 0
entry obj var ... 128. 0
entry stb var ... 128. 512.
entry sml fix ... 8. 512.
entry mlb fix ... 512. 512.
entry olb fix ... 8. 512.
entry msg fix ccr 64. 64.
entry jou var ccr 512. 0
entry stm stm ccr 512. 0 ; debugging
;V4
;
entry < > fix ... 512. 512.
;
;entry tsk fix ... 512. 512.
;entry exe fix ... 512. 512.
;entry sys fix ... 512. 512.
;entry mlb fix ... 512. 512.

For RTX.TSK I'd do something similar for output file types, but make
it possible to do runtime definitions.

In fact the RT-11 directory structure is extensible--you can specify a
fixed number of extra words per directory entry when a volume is
initialized. I already use that to store an RSX/VMS-compatible UIC and
protection mask, along with extended date and time information. So it
wouldn't be hard to add a few more words to track record structures,
but it hasn't really proven necessary.

The RUST/XM RSX feature got very little use. I wrote it because I
enjoyed the task, and it's been useful for me for various testing
issues. It still has some problems with libraries and some more
complex I/O, but the easy stuff works.

Ian

[Johnny Billquist]

On 2013-01-28 08:47, paramucho wrote:
> On Sat, 26 Jan 2013 00:39:04 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>> I should have pointed out that the simple emulator I'm sketching at
>>> the moment would not attempt to translate between RT-11 file
>>> structures and RSX file and record structures. That's a different
>>> task, and substantially more complex.
>>
>> I'll strip the rest of this subject, and just make this comment:
>> Aha. I see. Well, sure, that is certainly doable, and a lot easier. Not
>> that your files will be very useful under RSX, but you already know that.
>
> Er, well, hmm, sure, yikes, I guess...

I mean, what you'll get are files that is essentially stream files, from
RSX point of view, as that is what RT-11 produce natively. And just
about nothing will be able to access those files in RSX, unless you
write your own programs, or possibly use RMSCNV to convert the files to
another format. (I have not found RMSCNV to be very user friendly, so I
would not recommend using it, but there isn't much of anything else
around either...)
For files other than text files, the conversion becomes even more
complex, so I won't go into that...
Except of course files which actually would be fixed length 512 record
files in RSX, which would be correct from the start.
However, it also becomes a question of what attributes to set for the
files you create from your RT-11 program... Stream, or fixed 512 byte
records?

>>> As you say, FIP is a a special case which is specifically written to
>>> handle both file and record systems in some manner. There may well be
>>> hidden little trap doors in the emulated workspace to call RTEM.TSK to
>>> handle FCS. I've already noted device vector @#250 providing some kind
>>> of entry point. Testing with something like a system call trace is
>>> required to answer this kind of question, although an intelligent
>>> PDP-11 instruction dump of FIP would also provide a number of clues.
>>> (and DUMP.SAV is an example of a program which could be used
>>> meaningfully in RTX.TSK).
>>
>> Well, since FIP is an RT-11 program to start with, why not run DUMP.SAV
>> directly, and look at it?
>
> I don't have an RTEM kit or FIP. I'd run tests on all of it if I did.
> All I've managed to find on the web is a copy of JOAT.SAV.

I have FIP. Let me know if/how you'd like a copy. I also happen to have
RTEM... However, I do not have a complete correct kit, so it's all in
the form of bits and pieces which don't always work correctly together.

>>> Sorry, poor RSX terminology again, I meant the file headers, and I
>>> confess I haven't looked at how you do that under RSX because I used
>>> RMS to do it under VAX/VMS. It wouldn't be a high priority for a first
>>> version of RTX.TSK.
>>
>> The file header is actually located in INDEXF.SYS. But the way to read
>> that information is through QIO. That is what IO.RAT and IO.WAT does.
>> (Read/Write attributes)
>> The directory file as such only holds the file name, and file id.
>> Nothing more. It's just a simple mapping from name to FID.
>
> So that's why I remember INDEXF.SYS. I did a lot of work on this for
> the VMS network and AME many years ago and sort-of half remember it
> from then.

Yes, it's just that you normally never read INDEXF.SYS yourself. It's
done through F11ACP, using special QIO functions.

>>> Yes, the trace it's reporting a world that exists somewhere between
>>> the RSX app and the RUST operating system. There is no RSX file
>>> structure available in RUST. RSX programs run out of RT-11 directories
>>> and use files in RSX directories. I fudge the record-level
>>> descriptors, based on file types. But that's a whole different story.
>>
>> Aha. So IO.FNA in RUST pretty much ignores the DID field then, I assume?
>
> Yep.
>
> RT-11 directories are single-directory devices on RT-11 and RUST/XM. I
> have sub-directory support on RUST/SJ and when I finally port that to
> RUST/XM I'll probably use the DID for something meaningful.

Right. Which is why I suspected, assumed, that RUST would ignore the DID.

And by the way, the way of RSX means that arbitrary subdirectory
structures works just fine. The things that cause problems with
subdirectory trees in RSX is actually just wildcarding, which becomes
complicated...

>>> Then you have things like MACRO libraries which have mixed record
>>> types.
>>>
>>> All that said, in the example above PIP.TSK happily sends the RT-11
>>> file RUST.COM to the terminal in a coherent way. But that's the
>>> exception.
>>
>> Hmm. What do you return back for the IO.RAT function in RUST?
>
> That is the right question. I fudge it according to the file type
> using the following table. I forget how the table works, or if it
> really works all that well. I guess STM is experimental.

Ah... Well, that is a fair shortcut, I guess. Do you then also mangle
the contents to match when you actually access the files?

Johnny

[paramucho]

On Mon, 28 Jan 2013 19:06:05 +0100, Johnny Billquist <b...@softjar.se>

As I said earlier, I wrote essentially the same tool for VAX/VMS. I
guess I didn't really use it that much on text files and the like. It
was more DUMP and PATCH of 512. byte binaries, or stand-alone
utilities.

Note that RT-11 programs running the emulator can easily exchange
files with each other. I have that situation with the RSX emulator
running under RUST/XM where I sometimes MACRO and TKB a test source in
RSX format.

I also used to have, and maybe still do have, an editor which would
read/write RT-11 or RSX text file formats. Some RUST apps also detect
and process RSX text files correctly.

So, it's not really as much a problem as you suspect.

In any case, the tool is not designed to be used on a daily basis, but
more to be a specialist tool in the tool kit.

<snip>

>> I don't have an RTEM kit or FIP. I'd run tests on all of it if I did.
>> All I've managed to find on the web is a copy of JOAT.SAV.
>
>I have FIP. Let me know if/how you'd like a copy. I also happen to have
>RTEM... However, I do not have a complete correct kit, so it's all in
>the form of bits and pieces which don't always work correctly together.

Many thanks. I'll e-mail you.

<snip>

> RT-11 directories are single-directory devices on RT-11 and RUST/XM. I
>> have sub-directory support on RUST/SJ and when I finally port that to
>> RUST/XM I'll probably use the DID for something meaningful.
>
>Right. Which is why I suspected, assumed, that RUST would ignore the DID.
>
>And by the way, the way of RSX means that arbitrary subdirectory
>structures works just fine. The things that cause problems with
>subdirectory trees in RSX is actually just wildcarding, which becomes
>complicated...

One project I never got around to doing was to support FILES11A under
RUST/XM...

>>>> Then you have things like MACRO libraries which have mixed record
>>>> types.
>>>>
>>>> All that said, in the example above PIP.TSK happily sends the RT-11
>>>> file RUST.COM to the terminal in a coherent way. But that's the
>>>> exception.
>>>
>>> Hmm. What do you return back for the IO.RAT function in RUST?
>>
>> That is the right question. I fudge it according to the file type
>> using the following table. I forget how the table works, or if it
>> really works all that well. I guess STM is experimental.
>
>Ah... Well, that is a fair shortcut, I guess. Do you then also mangle
>the contents to match when you actually access the files?

I used the RSX emulator under RUST/XM to work with native RSX files,
so the fudged record attributes described the actual structure.

As I said above, it's not the kind of tool you used all the time.

I have, of course, thought of automated on-the-fly full conversion,
mostly because that would allow me to more-or-less legally use MACRO
from the RSX Professional distribution under RUST/XM. But I have
always had enough other icky projects to keep me happy without doing
that beast.

I did a bit more work on RTX.TSK over the weekend. I had planned to
reuse the code from a tiny RT-11 system I wrote as a stand-alone
bootstrap manager for RUST. But I soon worked out that I was going
need more functionality from RUST/SJ and that it would actually be
less work to adapt RUST/SJ for use under RSX. Well, that's the
thinking today. An adapted RUST/SJ solution would be more like RTEM I
guess, but I would still have it running out of RSX directories.




Ian

[Johnny Billquist]

It is only a problem if you want files transportable between RT-11 and
RSX. If you don't care about that, then I'd definitely just go with raw
block access, as that matches what RT-11 expects.

>> RT-11 directories are single-directory devices on RT-11 and RUST/XM. I
>>> have sub-directory support on RUST/SJ and when I finally port that to
>>> RUST/XM I'll probably use the DID for something meaningful.
>>
>> Right. Which is why I suspected, assumed, that RUST would ignore the DID.
>>
>> And by the way, the way of RSX means that arbitrary subdirectory
>> structures works just fine. The things that cause problems with
>> subdirectory trees in RSX is actually just wildcarding, which becomes
>> complicated...
>
> One project I never got around to doing was to support FILES11A under
> RUST/XM...

Would be cool, but at the same time require a lot more code, which is
why DEC never did this, as far as I understand.

Even without the FCS layer used by RSX, F11 could be used "natively" in
RT-11. You'd get hierarchical file structures, support for non-contigous
files, support for larger devices and files, and get something
semi-transportable to RSX.
Also support for lots of more information in a standardized way for each
file.

>>>>> Then you have things like MACRO libraries which have mixed record
>>>>> types.
>>>>>
>>>>> All that said, in the example above PIP.TSK happily sends the RT-11
>>>>> file RUST.COM to the terminal in a coherent way. But that's the
>>>>> exception.
>>>>
>>>> Hmm. What do you return back for the IO.RAT function in RUST?
>>>
>>> That is the right question. I fudge it according to the file type
>>> using the following table. I forget how the table works, or if it
>>> really works all that well. I guess STM is experimental.
>>
>> Ah... Well, that is a fair shortcut, I guess. Do you then also mangle
>> the contents to match when you actually access the files?
>
> I used the RSX emulator under RUST/XM to work with native RSX files,
> so the fudged record attributes described the actual structure.

Ah! That would do nicely.

> As I said above, it's not the kind of tool you used all the time.
>
> I have, of course, thought of automated on-the-fly full conversion,
> mostly because that would allow me to more-or-less legally use MACRO
> from the RSX Professional distribution under RUST/XM. But I have
> always had enough other icky projects to keep me happy without doing
> that beast.

It's not entirely trivial if you want to do it... I have had similar
thoughts and ponderings about potentially doing NFS for RSX, and then
what to do with those pesky Unix files...

> I did a bit more work on RTX.TSK over the weekend. I had planned to
> reuse the code from a tiny RT-11 system I wrote as a stand-alone
> bootstrap manager for RUST. But I soon worked out that I was going
> need more functionality from RUST/SJ and that it would actually be
> less work to adapt RUST/SJ for use under RSX. Well, that's the
> thinking today. An adapted RUST/SJ solution would be more like RTEM I
> guess, but I would still have it running out of RSX directories.

RTEM uses a virtual disk, with a normal RT-11 file system.

Still curious how FIP actually works, though. But we'll take that offline.

Johnny

[paramucho]

On Wed, 30 Jan 2013 19:50:57 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>> One project I never got around to doing was to support FILES11A under
>> RUST/XM...
>
>Would be cool, but at the same time require a lot more code, which is
>why DEC never did this, as far as I understand.

Actually, I forgot that one of my staff did write a read-only ACP for
Files-11A (based on an emergency import app I wrote when my VAX-11/730
crashed because all the sources were on VMS disks).

Regarding RT-11 and FILES11A, I heard a very curious story many years
ago that during the initial design for RT-11 they looked at using a
subset of FILES11A but rejected it because it would have required an
additional 30 words of memory.

Now, that might seem wierd to you (and it still does to me), but you
have to remember that the original RT-11 developers came from the
PDP-8 OS-8 team (the original sources had macros which emulated some
PDP-8 instructions), and they counted every byte.

But, on the other hand, I don't know how they would have squeezed any
implementation of FILES11A into the 2kw fixed space allocated for the
RT-11 "USR" (read "ACP"). Perhaps they only included support for
contiguous files (as RT-11 does), which would mean that they only
needed to access the index file during open and close operations and
wouldn't need to store window information (apart from the start
block). But, I'm still not sure what an effective allocation routine
would look like in that case.

>> I have, of course, thought of automated on-the-fly full conversion,
>> mostly because that would allow me to more-or-less legally use MACRO
>> from the RSX Professional distribution under RUST/XM. But I have
>> always had enough other icky projects to keep me happy without doing
>> that beast.
>
>It's not entirely trivial if you want to do it... I have had similar
>thoughts and ponderings about potentially doing NFS for RSX, and then
>what to do with those pesky Unix files...

It's the sort of job that never gets completely finished.

>> I did a bit more work on RTX.TSK over the weekend. I had planned to
>> reuse the code from a tiny RT-11 system I wrote as a stand-alone
>> bootstrap manager for RUST. But I soon worked out that I was going
>> need more functionality from RUST/SJ and that it would actually be
>> less work to adapt RUST/SJ for use under RSX. Well, that's the
>> thinking today. An adapted RUST/SJ solution would be more like RTEM I
>> guess, but I would still have it running out of RSX directories.
>
>RTEM uses a virtual disk, with a normal RT-11 file system.

The thing about RTEM and an adapted RUST/SJ is that most of the work
of emulation moves to the drivers. So, I would support normal RT-11
file systems easily (once they were mounted), but I would also support
transparent access to the native RSX systems, and, under V11, access
to Windows directories.

I did a bit of work on the RUST/SJ monitor sources yesterday. It turns
out that the monitor itself requires only a few modifications, mostly
for PSW access and for the terminal. The secondary bootstrap needs to
be almost fully rewritten and along with the media drivers.

>Still curious how FIP actually works, though. But we'll take that offline.

The thing I'm curious about at the moment is how RTEM emulates the
operation of the PSW as the basis of blocking mechanisms to avoid race
conditions in the RTEM system code executing in user mode. The only
mechanism which I can think of is enable/disable AST recognition
(since only ASTs would interrupt RTEM system code).

Ian

[Johnny Billquist]

On 2013-02-02 13:51, paramucho wrote:
> On Wed, 30 Jan 2013 19:50:57 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
> <snip>
>>> One project I never got around to doing was to support FILES11A under
>>> RUST/XM...
>>
>> Would be cool, but at the same time require a lot more code, which is
>> why DEC never did this, as far as I understand.
>
> Actually, I forgot that one of my staff did write a read-only ACP for
> Files-11A (based on an emergency import app I wrote when my VAX-11/730
> crashed because all the sources were on VMS disks).

For what? I mean, both VMS and RSX already have a Files-11A ACP. RT-11
then? But it wouldn't be an ACP, actually... But anyway, nice if you
could read Files-11A.

> Regarding RT-11 and FILES11A, I heard a very curious story many years
> ago that during the initial design for RT-11 they looked at using a
> subset of FILES11A but rejected it because it would have required an
> additional 30 words of memory.
>
> Now, that might seem wierd to you (and it still does to me), but you
> have to remember that the original RT-11 developers came from the
> PDP-8 OS-8 team (the original sources had macros which emulated some
> PDP-8 instructions), and they counted every byte.

Not at all that surprised, more than the fact that it would only have
been 30 words overweight.

I've used OS/8 for so long, and so much, that I at one time knew it
about as intimately as RSX. I've forgotten a lot, but every time I peek
at RT-11 I'm still amazed at how many things are so much like OS/8. :-)

> But, on the other hand, I don't know how they would have squeezed any
> implementation of FILES11A into the 2kw fixed space allocated for the
> RT-11 "USR" (read "ACP"). Perhaps they only included support for
> contiguous files (as RT-11 does), which would mean that they only
> needed to access the index file during open and close operations and
> wouldn't need to store window information (apart from the start
> block). But, I'm still not sure what an effective allocation routine
> would look like in that case.

Let me just point out that an ACP is nothing like USR. But yeah, I don't
really see how they could squeeze any Files-11 support into the space
the USR takes.

Is the USR resident in RT-11, or is it invisible to the application,
like in OS/8?

(Just for the sake of terminology, an ACP is an extension to a device
driver. It can implement just about anything, extending the
functionality of the device driver, such as different file systems,
communication protocols, or anything else. The ACP itself is a "normal"
privileged program that is scheduled just like any other program by the
kernel. It does, however, get passed some I/O operations that programs
queue to the device driver. The programs, as well as the device driver,
is unaware that the I/O requests actually end up at another program
instead. The ACP can then do I/O, do networking, IPC, or just
computations, as much as it wants, and eventually indicate that the I/O
request is done.)

>>> I have, of course, thought of automated on-the-fly full conversion,
>>> mostly because that would allow me to more-or-less legally use MACRO
>>> from the RSX Professional distribution under RUST/XM. But I have
>>> always had enough other icky projects to keep me happy without doing
>>> that beast.
>>
>> It's not entirely trivial if you want to do it... I have had similar
>> thoughts and ponderings about potentially doing NFS for RSX, and then
>> what to do with those pesky Unix files...
>
> It's the sort of job that never gets completely finished.

Maybe. I'll see if I ever get around to an NFS for RSX. I have other
fishes to fry first. Right now I'm in the middle of a rewrite of my TCP
implementation, to reduce the data copying...

> I did a bit of work on the RUST/SJ monitor sources yesterday. It turns
> out that the monitor itself requires only a few modifications, mostly
> for PSW access and for the terminal. The secondary bootstrap needs to
> be almost fully rewritten and along with the media drivers.

RT-11 have special code for RTEM, unless I remember wrong.

>> Still curious how FIP actually works, though. But we'll take that offline.
>
> The thing I'm curious about at the moment is how RTEM emulates the
> operation of the PSW as the basis of blocking mechanisms to avoid race
> conditions in the RTEM system code executing in user mode. The only
> mechanism which I can think of is enable/disable AST recognition
> (since only ASTs would interrupt RTEM system code).

ASTs (if we talk just RSX) never modify the PSW anyway.

But I don't know exactly what you are thinking of here, so I can't
really comment.

Johnny

[Jerome H. Fine]

>Johnny Billquist wrote:

> >On 2013-02-02 13:51, paramucho wrote:
>
>> Regarding RT-11 and FILES11A, I heard a very curious story many years
>> ago that during the initial design for RT-11 they looked at using a
>> subset of FILES11A but rejected it because it would have required an
>> additional 30 words of memory.
>>
>> Now, that might seem wierd to you (and it still does to me), but you
>> have to remember that the original RT-11 developers came from the
>> PDP-8 OS-8 team (the original sources had macros which emulated some
>> PDP-8 instructions), and they counted every byte.
>
>
> Not at all that surprised, more than the fact that it would only have
> been 30 words overweight.

Just to emphasize the above aspect, RT-11 supports
a SYSGEN capability (I seem to remember that RSX-11
does a well) which consists of more than a HUNDRED
options which the user is able to answer to taylor the
final RT-11 Monitor to support the selection of features
that the user wants RT-11 to support.

One of the features is the ability of the RT-11 monitor
to correctly change the date at the end of the month and
the end of the year (which is also the end of the month).
That also requires around 30 additional words in the
RT-11 monitor which probably many users don't require.

If the option is not selected, the date is still able to change
at the end of every day, but the user would need to manually
switch to the following month.

I think that the ROLLOVER of the date at the end of the
month being an option at the user's request illustrates just
how much emphasis the RT-11 developers placed on saving
a few words of memory in the RT-11 Monitor.

What is interesting is that it is possible to place all of that
additional code in extended memory, probably along with
at least a few other aspects of the RT-11 Monitor for
Mapped Monitors such as RT11XM. That might have
been the intention of the RT-11 developers, but they
never had the opportunity after V05.06 in 1992 after
which DEC effectively abandoned RT-11 development.

When Mentec added the Y2K code to RT-11 and released
it in 1998 as V05.07 along with a few other bugs being
fixed, very few outstanding additional bugs were corrected
and they still remain in RT-11. Fortunately, many have a
work around, including a few which cause RT-11 to crash.

Jerome Fine

[paramucho]

On Sat, 02 Feb 2013 17:15:19 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> Actually, I forgot that one of my staff did write a read-only ACP for
>> Files-11A (based on an emergency import app I wrote when my VAX-11/730
>> crashed because all the sources were on VMS disks).
>
>For what? I mean, both VMS and RSX already have a Files-11A ACP. RT-11
>then? But it wouldn't be an ACP, actually... But anyway, nice if you
>could read Files-11A.

The ACP was for RUST/XM and was implemented as a separate process with
a request queue for directory operations and special handling for
virtual-to-logical block mapping etc. It was a project that the staff
member wanted to do for his own edification and enjoyment.

>> Regarding RT-11 and FILES11A, I heard a very curious story many years
>> ago that during the initial design for RT-11 they looked at using a
>> subset of FILES11A but rejected it because it would have required an
>> additional 30 words of memory.
>>
>> Now, that might seem wierd to you (and it still does to me), but you
>> have to remember that the original RT-11 developers came from the
>> PDP-8 OS-8 team (the original sources had macros which emulated some
>> PDP-8 instructions), and they counted every byte.
>
>Not at all that surprised, more than the fact that it would only have
>been 30 words overweight.
>
>I've used OS/8 for so long, and so much, that I at one time knew it
>about as intimately as RSX. I've forgotten a lot, but every time I peek
>at RT-11 I'm still amazed at how many things are so much like OS/8. :-)

RT-11 was designed to provide the same kind of environment that OS-8
provided for the PDP-8. Using some of the OS-8 developers on the
initial system probably sped up the design time and brought their
practical experience to the initial implementation.

>Let me just point out that an ACP is nothing like USR. But yeah, I don't
>really see how they could squeeze any Files-11 support into the space
>the USR takes.

The implementationa are different, as you note, but the USR is
functionally similar to an ACP in that it fields directory operations.
RT-11 has a contiguous file structure so the the USR does not have to
deal with mapping virtual blocks. It's the functionality that is
similar, not the implementation.

Early versions of VMS had separate FILES11B ACP processes just as RSX
does. I think that later versions moved to more of an RT-11 model
where FILES11B ACP operations take place in the context of the calling
process.

>Is the USR resident in RT-11, or is it invisible to the application,
>like in OS/8?

Both. The USR can be made permanent with SET USR NOSWAP and a program
can lock/unlock the USR in memory. Otherwise it is loaded into a 2kw
area of memory to handle directory system calls and some other stuff.
The operation is largely transparent to programs.

RUST/SJ used to have a sort-of swapping USR but I merged the code with
the monitor more recently, so it's permanent.

RUST/XM extends the RT-11 model giving each process essentially it's
own "USR". Processes only queue for directory access when a directory
modification is in progress. Otherwise, directory operations for a
given volume can be fully overlapped. RUST/XM also supports ACP-like
processes for other file structures, but it's a bit cumbersome.

>(Just for the sake of terminology, an ACP is an extension to a device
>driver. It can implement just about anything, extending the
>functionality of the device driver, such as different file systems,
>communication protocols, or anything else. The ACP itself is a "normal"
>privileged program that is scheduled just like any other program by the
>kernel. It does, however, get passed some I/O operations that programs
>queue to the device driver. The programs, as well as the device driver,
>is unaware that the I/O requests actually end up at another program
>instead. The ACP can then do I/O, do networking, IPC, or just
>computations, as much as it wants, and eventually indicate that the I/O
>request is done.)

That's why they're called "ancilliary control processes" and that's
how the FILES11A functionality was implemented under RUST/XM.

In RT-11 (and RUST systems) "special directory" drivers are sometimes
used to implement similar kinds of functionality. They pick up a
driver call, preprocess it and may then requeue to a separate driver.
That's how networks are implemented under RUST/XM.

<snip>

>> I did a bit of work on the RUST/SJ monitor sources yesterday. It turns
>> out that the monitor itself requires only a few modifications, mostly
>> for PSW access and for the terminal. The secondary bootstrap needs to
>> be almost fully rewritten and along with the media drivers.
>
>RT-11 have special code for RTEM, unless I remember wrong.

Yes, the resident monitor (RMON) has a relatively small number of
conditionals for RTEM. There's nothing in the USR or KMON except for
the conditions controlling the MACRO title of the module. It's the
bootstrap which has a lot of changes. Then there's all the code in
RTEM.TSK itself. I guess the drivers are completely rewritten for RTEM
and would send calls to the RSX native code in RTEM.TSK.

>>> Still curious how FIP actually works, though. But we'll take that offline.
>>
>> The thing I'm curious about at the moment is how RTEM emulates the
>> operation of the PSW as the basis of blocking mechanisms to avoid race
>> conditions in the RTEM system code executing in user mode. The only
>> mechanism which I can think of is enable/disable AST recognition
>> (since only ASTs would interrupt RTEM system code).
>
>ASTs (if we talk just RSX) never modify the PSW anyway.
>
>But I don't know exactly what you are thinking of here, so I can't
>really comment.

In a real, native version of RT-11 or RSX the PSW is used in the
implementation of queueing for various resources and in entering and
leaving system state (such as ENSYS/FORK). We've discussed this topic
previously.

Under RTEM the PSW is not available because the RTEM monitor runs in
user mode, not kernel mode. Asynchronous hardware interrupts do not
occur in user mode, of course, but ASTs (for the clock, terminal or
other I/O) can interrupt user mode monitor operations. The RTEM user
mode monitor needs to be able to block such ASTS if it is to maintain
the integrity of its queue structures etc.

I had a more detailed look today. All accesses to the PSW in the RTEM
conditional assembly of the RT-11 monitor are converted to calls to
special RTEM routines. I guess it's those routines which manage ASTs.

Ian

[Johnny Billquist]

On 2013-02-04 13:03, paramucho wrote:
> On Sat, 02 Feb 2013 17:15:19 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>> Actually, I forgot that one of my staff did write a read-only ACP for
>>> Files-11A (based on an emergency import app I wrote when my VAX-11/730
>>> crashed because all the sources were on VMS disks).
>>
>> For what? I mean, both VMS and RSX already have a Files-11A ACP. RT-11
>> then? But it wouldn't be an ACP, actually... But anyway, nice if you
>> could read Files-11A.
>
> The ACP was for RUST/XM and was implemented as a separate process with
> a request queue for directory operations and special handling for
> virtual-to-logical block mapping etc. It was a project that the staff
> member wanted to do for his own edification and enjoyment.

Ok. Cool.

>>> Regarding RT-11 and FILES11A, I heard a very curious story many years
>>> ago that during the initial design for RT-11 they looked at using a
>>> subset of FILES11A but rejected it because it would have required an
>>> additional 30 words of memory.
>>>
>>> Now, that might seem wierd to you (and it still does to me), but you
>>> have to remember that the original RT-11 developers came from the
>>> PDP-8 OS-8 team (the original sources had macros which emulated some
>>> PDP-8 instructions), and they counted every byte.
>>
>> Not at all that surprised, more than the fact that it would only have
>> been 30 words overweight.
>>
>> I've used OS/8 for so long, and so much, that I at one time knew it
>> about as intimately as RSX. I've forgotten a lot, but every time I peek
>> at RT-11 I'm still amazed at how many things are so much like OS/8. :-)
>
> RT-11 was designed to provide the same kind of environment that OS-8
> provided for the PDP-8. Using some of the OS-8 developers on the
> initial system probably sped up the design time and brought their
> practical experience to the initial implementation.

Pretty much what I had understood. It makes it dangerous for me to
comment on RT-11, because I know OS/8 and sometimes jumps to conclusions
about RT-11, but occasionally I'm totally wrong. :-)

>> Let me just point out that an ACP is nothing like USR. But yeah, I don't
>> really see how they could squeeze any Files-11 support into the space
>> the USR takes.
>
> The implementationa are different, as you note, but the USR is
> functionally similar to an ACP in that it fields directory operations.
> RT-11 has a contiguous file structure so the the USR does not have to
> deal with mapping virtual blocks. It's the functionality that is
> similar, not the implementation.

Right. However, technically, an ACP is unique (or could be) per device.
And an ACP can implement other operations/things than directory operations.
Actually, in theory, the ACP is involved in every operation done on a
file, even each read or write, since it is the ACP that understands
files. And the ACP provides the mapping between the file virtual blocks
and the device physical blocks. (But see more below.)

But for the common case, I guess it's fair to compare USR with an ACP.

> Early versions of VMS had separate FILES11B ACP processes just as RSX
> does. I think that later versions moved to more of an RT-11 model
> where FILES11B ACP operations take place in the context of the calling
> process.

Actually, if I remember right, VMS moved the ACP into the kernel to
avoid having the context switches of a separate process, but
functionality-wise it didn't change.
This is called an XQP. However, ACPs can, and still do exist as well.

I don't know all details of VMS here, but for RSX, the F11ACP is sortof
a hybrid. Complex operations like file opening, or directory enters and
so on, are done within the context of the ACP, which then force a
serialization of these operations. However, file reads/writes, which
technically also needs to go through the ACP are actually caught in the
kernel, and completed without really going through the ACP most of the
time. All the data needed to block remapping are available, so the
kernel can do this with the help of those data structures, and still
remain within the context of the process doing the I/O operations.

>> Is the USR resident in RT-11, or is it invisible to the application,
>> like in OS/8?
>
> Both. The USR can be made permanent with SET USR NOSWAP and a program
> can lock/unlock the USR in memory. Otherwise it is loaded into a 2kw
> area of memory to handle directory system calls and some other stuff.
> The operation is largely transparent to programs.

Sounds like OS/8 in that case. Unless you lock it in memory, it does not
occupy any of your address space, but gets swapped in and out
transparently to the program.

>>> I did a bit of work on the RUST/SJ monitor sources yesterday. It turns
>>> out that the monitor itself requires only a few modifications, mostly
>>> for PSW access and for the terminal. The secondary bootstrap needs to
>>> be almost fully rewritten and along with the media drivers.
>>
>> RT-11 have special code for RTEM, unless I remember wrong.
>
> Yes, the resident monitor (RMON) has a relatively small number of
> conditionals for RTEM. There's nothing in the USR or KMON except for
> the conditions controlling the MACRO title of the module. It's the
> bootstrap which has a lot of changes. Then there's all the code in
> RTEM.TSK itself. I guess the drivers are completely rewritten for RTEM
> and would send calls to the RSX native code in RTEM.TSK.

Probably, one way or another. Don't make sense to try and emulate things
at a low level. Device driver level seems the most efficient, and then a
corresponding side in RTEM that ends up in RSX files.

>>>> Still curious how FIP actually works, though. But we'll take that offline.
>>>
>>> The thing I'm curious about at the moment is how RTEM emulates the
>>> operation of the PSW as the basis of blocking mechanisms to avoid race
>>> conditions in the RTEM system code executing in user mode. The only
>>> mechanism which I can think of is enable/disable AST recognition
>>> (since only ASTs would interrupt RTEM system code).
>>
>> ASTs (if we talk just RSX) never modify the PSW anyway.
>>
>> But I don't know exactly what you are thinking of here, so I can't
>> really comment.
>
> In a real, native version of RT-11 or RSX the PSW is used in the
> implementation of queueing for various resources and in entering and
> leaving system state (such as ENSYS/FORK). We've discussed this topic
> previously.
>
> Under RTEM the PSW is not available because the RTEM monitor runs in
> user mode, not kernel mode. Asynchronous hardware interrupts do not
> occur in user mode, of course, but ASTs (for the clock, terminal or
> other I/O) can interrupt user mode monitor operations. The RTEM user
> mode monitor needs to be able to block such ASTS if it is to maintain
> the integrity of its queue structures etc.
>
> I had a more detailed look today. All accesses to the PSW in the RTEM
> conditional assembly of the RT-11 monitor are converted to calls to
> special RTEM routines. I guess it's those routines which manage ASTs.

Ah. You meant that way.
Yes, inasmuch the flow of execution can be interrupted, you need a way
to block it in some places.
I guess timers would be a typical example of this, as you probably can't
accept timers to trigger at any random point in the code.

Blocking ASTs in RTEM would probably be what you want/need to do instead
of raising the IPL.

Johnny

[paramucho]

On Mon, 04 Feb 2013 17:58:12 +0100, Johnny Billquist <b...@softjar.se>
wrote:
<SNIP>

>> I had a more detailed look today. All accesses to the PSW in the RTEM
>> conditional assembly of the RT-11 monitor are converted to calls to
>> special RTEM routines. I guess it's those routines which manage ASTs.
>
>Ah. You meant that way.
>Yes, inasmuch the flow of execution can be interrupted, you need a way
>to block it in some places.
>I guess timers would be a typical example of this, as you probably can't
>accept timers to trigger at any random point in the code.
>
>Blocking ASTs in RTEM would probably be what you want/need to do instead
>of raising the IPL.

In fact, it turns out that it's necessary to get rid of an AST which
emulates an interrupt (for example the keyboard) with ASTX$ before the
"interrupt" code executes. That's because there's no guarantee that
the "interrupt" code will return along the path which issues an ASTX$.
It's a matter of rebuilding the AST stack.

I got a development version of RTX.TSK working this week. Very little
code required. At present it has pretty much everything done except
for the driver which talks to the RSX file system. For the development
phase I'm using a little driver which hooks up to V11 to access native
Windows directories independently of RSX.

The only problem I have at present is that every so often I enter XDT
with an unidentified CRASH. I've searched through all the RSX media I
have but I can't find the source of the CRASH. It always occurs when
I'm typing characters--in fact, the keyboard is the only asynchronous
event at present. The crash is intermittent. It might have something
to do with my ASTX$ trickery.

13214k 10200 mov r2,r0 |
13216k 10160 mov r1,2(r0) |
13222k 22726 cmp #11114,(sp)+ |
13226k 1007 bne 13246 |
13230k 26767 cmp 11206,11212 |
13236k 101403 blos 13246 |
13240k 12702 mov #401,r2 |
13244k 404 br 13256 |
13246k 207 return |
13250k 5703 tst r3 |
13252k 1745 beq 13166 |
13254k 4 iot | ; XDT CRASH
13256k 130267 bitb r2,11210 |
13262k 1021 bne 13326 |
13264k 150267 bisb r2,11210 |
13270k 105002 clrb r2 |
13272k 30267 bit r2,11210 |
13276k 1013 bne 13326 |
13300k 10046 psh r0 |
13302k 16700 mov 11204,r0 |
13306k 1406 beq 13324 |
13310k 10146 psh r1 |

It could be something really stupid because I know so little about
RSX. For example, it took me a day to realize that the vector table
specified by SVTK$ had to remain mapped after the directive!

Ian

[Johnny Billquist]

On 2013-02-15 13:34, paramucho wrote:
> On Mon, 04 Feb 2013 17:58:12 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
> <SNIP>
>
>>> I had a more detailed look today. All accesses to the PSW in the RTEM
>>> conditional assembly of the RT-11 monitor are converted to calls to
>>> special RTEM routines. I guess it's those routines which manage ASTs.
>>
>> Ah. You meant that way.
>> Yes, inasmuch the flow of execution can be interrupted, you need a way
>> to block it in some places.
>> I guess timers would be a typical example of this, as you probably can't
>> accept timers to trigger at any random point in the code.
>>
>> Blocking ASTs in RTEM would probably be what you want/need to do instead
>> of raising the IPL.
>
> In fact, it turns out that it's necessary to get rid of an AST which
> emulates an interrupt (for example the keyboard) with ASTX$ before the
> "interrupt" code executes. That's because there's no guarantee that
> the "interrupt" code will return along the path which issues an ASTX$.
> It's a matter of rebuilding the AST stack.

I'm not sure I understand the problem.
So, you press a key. RSX generates an AST. You call the interrupt code
in RT-11. Is RT-11 assuming that this is a real interrupt? Ie., do RT-11
return with an RTI? I would have thought you'd want to create an
interrupt stack frame before calling into RT-11 in that case.
Or are you stepping in at a higher level where the hardware interrupt
have already been dealt with, and it's just a call into somewhere? Still
seems weird if it don't do a return sooner or later?

I must be missing something here.

> I got a development version of RTX.TSK working this week. Very little
> code required. At present it has pretty much everything done except
> for the driver which talks to the RSX file system. For the development
> phase I'm using a little driver which hooks up to V11 to access native
> Windows directories independently of RSX.

Cool.

> The only problem I have at present is that every so often I enter XDT
> with an unidentified CRASH. I've searched through all the RSX media I
> have but I can't find the source of the CRASH. It always occurs when
> I'm typing characters--in fact, the keyboard is the only asynchronous
> event at present. The crash is intermittent. It might have something
> to do with my ASTX$ trickery.

Isn't that done at user level? I can't see how you could cause a crash
by that. Or did you poke in the internals of RSX to modify how ASTX$ works?

> 13214k 10200 mov r2,r0 |
> 13216k 10160 mov r1,2(r0) |
> 13222k 22726 cmp #11114,(sp)+ |
> 13226k 1007 bne 13246 |
> 13230k 26767 cmp 11206,11212 |
> 13236k 101403 blos 13246 |
> 13240k 12702 mov #401,r2 |
> 13244k 404 br 13256 |
> 13246k 207 return |
> 13250k 5703 tst r3 |
> 13252k 1745 beq 13166 |
> 13254k 4 iot | ; XDT CRASH
> 13256k 130267 bitb r2,11210 |
> 13262k 1021 bne 13326 |
> 13264k 150267 bisb r2,11210 |
> 13270k 105002 clrb r2 |
> 13272k 30267 bit r2,11210 |
> 13276k 1013 bne 13326 |
> 13300k 10046 psh r0 |
> 13302k 16700 mov 11204,r0 |
> 13306k 1406 beq 13324 |
> 13310k 10146 psh r1 |

You should search through RSX11M.MAP to find which module this is, and
where in that module. And then look at the code and figure out what is
going on.

Also, if you get to XDT, what you could do is just to do a crash dump,
and then run the crash dump analyzer on the output after reboot, and
find out more details on what happened, and why.

> It could be something really stupid because I know so little about
> RSX. For example, it took me a day to realize that the vector table
> specified by SVTK$ had to remain mapped after the directive!

Of course. :-)
The vector is a virtual address in your address space. Change the
mapping, and your pointer will point at something else. If it instead
were to store a physical address, your program would have to be locked
into memory, since any swapping might change your physical addresses...

[paramucho]

On Fri, 15 Feb 2013 14:08:48 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>On 2013-02-15 13:34, paramucho wrote:
>
>> In fact, it turns out that it's necessary to get rid of an AST which
>> emulates an interrupt (for example the keyboard) with ASTX$ before the
>> "interrupt" code executes. That's because there's no guarantee that
>> the "interrupt" code will return along the path which issues an ASTX$.
>> It's a matter of rebuilding the AST stack.
>
>I'm not sure I understand the problem.
>So, you press a key. RSX generates an AST. You call the interrupt code
>in RT-11. Is RT-11 assuming that this is a real interrupt? Ie., do RT-11
>return with an RTI? I would have thought you'd want to create an
>interrupt stack frame before calling into RT-11 in that case.
>Or are you stepping in at a higher level where the hardware interrupt
>have already been dealt with, and it's just a call into somewhere? Still
>seems weird if it don't do a return sooner or later?
>
>I must be missing something here.

Yes, RT-11 (i.e. RUST/SJ) assumes its an interrupt, so I have to build
an interrupt stack (PC, PS). However, I need to get rid of the AST
stack frame first.

To do that I move the AST frame down the stack to make space for the
keyboard vector PC/PS. Then I execute ASTX$ which gets rid of the AST
frame and enters the keyboard ISR. And that works (most of the time).

The keyboard interrupt usually returns, but may abort if two ^C's are
received.


<snip>

>> The only problem I have at present is that every so often I enter XDT
>> with an unidentified CRASH. I've searched through all the RSX media I
>> have but I can't find the source of the CRASH. It always occurs when
>> I'm typing characters--in fact, the keyboard is the only asynchronous
>> event at present. The crash is intermittent. It might have something
>> to do with my ASTX$ trickery.
>
>Isn't that done at user level? I can't see how you could cause a crash
>by that. Or did you poke in the internals of RSX to modify how ASTX$ works?

Yes, its at user level and, no, there's no poking around. And yes, I
shouldn't be able to cause a system crash in user mode.

<snip>

>You should search through RSX11M.MAP to find which module this is, and
>where in that module. And then look at the code and figure out what is
>going on.
>
>Also, if you get to XDT, what you could do is just to do a crash dump,
>and then run the crash dump analyzer on the output after reboot, and
>find out more details on what happened, and why.

I can't find CDA on any of the RSX .DSK files I have here. I'll keep
looking.

<snip>


Ian

[Johnny Billquist]

On 2013-02-15 16:15, paramucho wrote:
> On Fri, 15 Feb 2013 14:08:48 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>> On 2013-02-15 13:34, paramucho wrote:
>>
>>> In fact, it turns out that it's necessary to get rid of an AST which
>>> emulates an interrupt (for example the keyboard) with ASTX$ before the
>>> "interrupt" code executes. That's because there's no guarantee that
>>> the "interrupt" code will return along the path which issues an ASTX$.
>>> It's a matter of rebuilding the AST stack.
>>
>> I'm not sure I understand the problem.
>> So, you press a key. RSX generates an AST. You call the interrupt code
>> in RT-11. Is RT-11 assuming that this is a real interrupt? Ie., do RT-11
>> return with an RTI? I would have thought you'd want to create an
>> interrupt stack frame before calling into RT-11 in that case.
>> Or are you stepping in at a higher level where the hardware interrupt
>> have already been dealt with, and it's just a call into somewhere? Still
>> seems weird if it don't do a return sooner or later?
>>
>> I must be missing something here.
>
> Yes, RT-11 (i.e. RUST/SJ) assumes its an interrupt, so I have to build
> an interrupt stack (PC, PS). However, I need to get rid of the AST
> stack frame first.

Cool. But why get rid of the AST frame? Have the RTI return to your AST
code, which then do the ASTX$ would be the natural thing, I would have
thought.

> To do that I move the AST frame down the stack to make space for the
> keyboard vector PC/PS. Then I execute ASTX$ which gets rid of the AST
> frame and enters the keyboard ISR. And that works (most of the time).

Hmm. It should work, except that you need to keep track of your stack.
Some ASTs push some extra stuff on the stack, which I hope you are aware of.

> The keyboard interrupt usually returns, but may abort if two ^C's are
> received.

What do it do in that case? Jump to some random point, while just
setting a new PSW?

>>> The only problem I have at present is that every so often I enter XDT
>>> with an unidentified CRASH. I've searched through all the RSX media I
>>> have but I can't find the source of the CRASH. It always occurs when
>>> I'm typing characters--in fact, the keyboard is the only asynchronous
>>> event at present. The crash is intermittent. It might have something
>>> to do with my ASTX$ trickery.
>>
>> Isn't that done at user level? I can't see how you could cause a crash
>> by that. Or did you poke in the internals of RSX to modify how ASTX$ works?
>
> Yes, its at user level and, no, there's no poking around. And yes, I
> shouldn't be able to cause a system crash in user mode.

Interesting how you manage, then... This will be fun to find out.

>> You should search through RSX11M.MAP to find which module this is, and
>> where in that module. And then look at the code and figure out what is
>> going on.
>>
>> Also, if you get to XDT, what you could do is just to do a crash dump,
>> and then run the crash dump analyzer on the output after reboot, and
>> find out more details on what happened, and why.
>
> I can't find CDA on any of the RSX .DSK files I have here. I'll keep
> looking.

Um... What version of RSX are you actually running?

Maybe you've found a nice bug. There have been some bug fixes related to
ASTs over the years, as far as I can remember.

[paramucho]

On Fri, 15 Feb 2013 17:04:31 +0100, Johnny Billquist <b...@softjar.se>

wrote:

>>> On 2013-02-15 13:34, paramucho wrote:
>>>
>>>> In fact, it turns out that it's necessary to get rid of an AST which
>>>> emulates an interrupt (for example the keyboard) with ASTX$ before the
>>>> "interrupt" code executes. That's because there's no guarantee that
>>>> the "interrupt" code will return along the path which issues an ASTX$.
>>>> It's a matter of rebuilding the AST stack.
>>>
>>> I'm not sure I understand the problem.
>>> So, you press a key. RSX generates an AST. You call the interrupt code
>>> in RT-11. Is RT-11 assuming that this is a real interrupt? Ie., do RT-11
>>> return with an RTI? I would have thought you'd want to create an
>>> interrupt stack frame before calling into RT-11 in that case.
>>> Or are you stepping in at a higher level where the hardware interrupt
>>> have already been dealt with, and it's just a call into somewhere? Still
>>> seems weird if it don't do a return sooner or later?
>>>
>>> I must be missing something here.
>>
>> Yes, RT-11 (i.e. RUST/SJ) assumes its an interrupt, so I have to build
>> an interrupt stack (PC, PS). However, I need to get rid of the AST
>> stack frame first.
>
>Cool. But why get rid of the AST frame? Have the RTI return to your AST
>code, which then do the ASTX$ would be the natural thing, I would have
>thought.

See below.

However there is another reason as well. An AST blocks *all* other
ASTs, whereas an interrupt only blocks *some* other interrupts. For
example, a keyboard AST, which could take quite extensive processing,
can block a timer AST.

>> To do that I move the AST frame down the stack to make space for the
>> keyboard vector PC/PS. Then I execute ASTX$ which gets rid of the AST
>> frame and enters the keyboard ISR. And that works (most of the time).
>
>Hmm. It should work, except that you need to keep track of your stack.
>Some ASTs push some extra stuff on the stack, which I hope you are aware of.

Yes, I get rid of the ISB address which comes with a QIO AST.

The one thing that did confuse me was that the documentation spoke
about the "event flag word" which ended up being *four* words in
practice. The ASTX system code cleared that up.

>> The keyboard interrupt usually returns, but may abort if two ^C's are
>> received.
>
>What do it do in that case? Jump to some random point, while just
>setting a new PSW?

Standard operating procedure for program abort in an (unmapped) single
process RT-11/RUST system is to issue an abort I/O to each driver,
cancel timer requests etc and then restart the monitor. Abort can
occur in mainline or AST state. It's more dignified in RUST/XM etc.

In RTX that would mean that an ASTX could be lost in an abort.

>>>> The only problem I have at present is that every so often I enter XDT
>>>> with an unidentified CRASH. I've searched through all the RSX media I
>>>> have but I can't find the source of the CRASH. It always occurs when
>>>> I'm typing characters--in fact, the keyboard is the only asynchronous
>>>> event at present. The crash is intermittent. It might have something
>>>> to do with my ASTX$ trickery.
>>>
>>> Isn't that done at user level? I can't see how you could cause a crash
>>> by that. Or did you poke in the internals of RSX to modify how ASTX$ works?
>>
>> Yes, its at user level and, no, there's no poking around. And yes, I
>> shouldn't be able to cause a system crash in user mode.
>
>Interesting how you manage, then... This will be fun to find out.

That's what I've been thinking.

>>> You should search through RSX11M.MAP to find which module this is, and
>>> where in that module. And then look at the code and figure out what is
>>> going on.
>>>
>>> Also, if you get to XDT, what you could do is just to do a crash dump,
>>> and then run the crash dump analyzer on the output after reboot, and
>>> find out more details on what happened, and why.
>>
>> I can't find CDA on any of the RSX .DSK files I have here. I'll keep
>> looking.
>
>Um... What version of RSX are you actually running?

I am in a complete mess in that department. I've downloaded various
system disks over the years. I develop mostly under V11 which doesn't
support I/D space or MSCP, so I don't run M+ or large disks.

The last system I managed to put together was in response to some
issues you were having with RMS a couple of years ago (I think). It
reports the following:

RSX-11M V4.4 BL46 512.K MAPPED

>Maybe you've found a nice bug. There have been some bug fixes related to
>ASTs over the years, as far as I can remember.

My guess is that I'm doing something naive like I did with the user
mode vector table for SVTK$.

It took me awhile to work out that I needed to use Set Multiple
Characteristics to set up full duplex mode. Before I worked that out I
tried having separate LUNs for for the keyboard and terminal output,
and I have not gone back to a single LUN.

Keyboard input is asynchronous with an AST and passall. At present
terminal output is synchronous with no AST. The problem might be
related to this usage, but I can't imagine that what I've done there
would crash RSX. It can't be that easy.

I've wrapped both keyboard and terminal output QIOs in DSAR/ENARs, but
that doesn't stop the intermittent bug. There is a also a chance that
I could have a bug in V11. I've started working on the driver which
talks to the RSX file system. Once that's done RTX.TSK will be
operative under E11 and SimH (and real hardware) which would further
test the bug.

I have a question. RTX.TSK itself will go into [1,54], but I'm going
to need a separate RSX directory to hold the RTX.TSK system files and
applications--would there be any problems if I just chose a default
directory name such as [1,64] and use that? I can make the name
configurable in a .INI file, but I like to have a reliable default for
these things.

Ian

[Johnny Billquist]

Ah. Now, that is a very good point. Although code that spends lots of
time in an interrupt handler is not very nice code to start with.
But yeah, ASTs are all or nothing.

>>> To do that I move the AST frame down the stack to make space for the
>>> keyboard vector PC/PS. Then I execute ASTX$ which gets rid of the AST
>>> frame and enters the keyboard ISR. And that works (most of the time).
>>
>> Hmm. It should work, except that you need to keep track of your stack.
>> Some ASTs push some extra stuff on the stack, which I hope you are aware of.
>
> Yes, I get rid of the ISB address which comes with a QIO AST.

Excellent. And other type of ASTs might have other information on the
stack. And it might be more or less...

> The one thing that did confuse me was that the documentation spoke
> about the "event flag word" which ended up being *four* words in
> practice. The ASTX system code cleared that up.

Ayup. From LB:[11,10]DRATX.MAC (which implements the ASTX$ call)

; **-$DRATX-AST SERVICE EXIT
;
; THIS DIRECTIVE INSTRUCTS THE SYSTEM TO TERMINATE THE EXECUTION OF AN
; ASYNCHRONOUS SYSTEM TRAP SERVICE ROUTINE. IF ANOTHER AST IS QUEUED AND
; AST'S ARE NOT DISABLED, THEN THE NEXT AST IS EFFECTED IMMEDIATELY.
;
; DPB FORMAT:
;
; WD. 00 -- DIC(115.),DPB SIZE(1.).
;
; AT ISSUANCE THE TASK STACK CONTAINS:
;
; 14(SP)=EVENT FLAG MASK WORD FOR FLAGS 1.-16.
; 12(SP)=EVENT FLAG MASK WORD FOR FLAGS 17.-32.
; 10(SP)=EVENT FLAG MASK WORD FOR FLAGS 33.-48.
; 06(SP)=EVENT FLAG MASK WORD FOR FLAGS 49.-64.
; 04(SP)=PRE AST TASK PS.
; 02(SP)=PRE AST TASK PC.
; 00(SP)=PRE AST TASK DIRECTIVE STATUS WORD.

>>> The keyboard interrupt usually returns, but may abort if two ^C's are
>>> received.
>>
>> What do it do in that case? Jump to some random point, while just
>> setting a new PSW?
>
> Standard operating procedure for program abort in an (unmapped) single
> process RT-11/RUST system is to issue an abort I/O to each driver,
> cancel timer requests etc and then restart the monitor. Abort can
> occur in mainline or AST state. It's more dignified in RUST/XM etc.

Very similar to OS/8 then (again). Although OS/8 is more simple, since
it don't even use interrupts. It just restarts the monitor. And anything
might do that for any good reason, including the terminal device driver
detecting a ^C.

> In RTX that would mean that an ASTX could be lost in an abort.

Right. Not good. So you need to get rid of the AST completely before
getting back to RT-11. Oh well.

>>>> You should search through RSX11M.MAP to find which module this is, and
>>>> where in that module. And then look at the code and figure out what is
>>>> going on.
>>>>
>>>> Also, if you get to XDT, what you could do is just to do a crash dump,
>>>> and then run the crash dump analyzer on the output after reboot, and
>>>> find out more details on what happened, and why.
>>>
>>> I can't find CDA on any of the RSX .DSK files I have here. I'll keep
>>> looking.
>>
>> Um... What version of RSX are you actually running?
>
> I am in a complete mess in that department. I've downloaded various
> system disks over the years. I develop mostly under V11 which doesn't
> support I/D space or MSCP, so I don't run M+ or large disks.

Ouch. I'm way more rusty on 11M, since I haven't really played much with
it in the last 20 years, and sometimes there are subtle differences,
which are important.

> The last system I managed to put together was in response to some
> issues you were having with RMS a couple of years ago (I think). It
> reports the following:
>
> RSX-11M V4.4 BL46 512.K MAPPED

I remember that one. I was trying to figure out how RMS interacted with
various device attributes.

Rather old version. Ok...

>> Maybe you've found a nice bug. There have been some bug fixes related to
>> ASTs over the years, as far as I can remember.
>
> My guess is that I'm doing something naive like I did with the user
> mode vector table for SVTK$.

It should not be possible to crash RSX anyway.

> It took me awhile to work out that I needed to use Set Multiple
> Characteristics to set up full duplex mode. Before I worked that out I
> tried having separate LUNs for for the keyboard and terminal output,
> and I have not gone back to a single LUN.

Well, you could have just done it in MCR. SET /FDX=TI: :-)

> Keyboard input is asynchronous with an AST and passall. At present
> terminal output is synchronous with no AST. The problem might be
> related to this usage, but I can't imagine that what I've done there
> would crash RSX. It can't be that easy.

Such usage should be fine. Disregarding bugs, of course.

> I've wrapped both keyboard and terminal output QIOs in DSAR/ENARs, but
> that doesn't stop the intermittent bug. There is a also a chance that
> I could have a bug in V11. I've started working on the driver which
> talks to the RSX file system. Once that's done RTX.TSK will be
> operative under E11 and SimH (and real hardware) which would further
> test the bug.

Wrapping the QIOs like that should not make a difference, and I'm glad
to hear it don't. :-)

> I have a question. RTX.TSK itself will go into [1,54], but I'm going
> to need a separate RSX directory to hold the RTX.TSK system files and
> applications--would there be any problems if I just chose a default
> directory name such as [1,64] and use that? I can make the name
> configurable in a .INI file, but I like to have a reliable default for
> these things.

Please keep in mind that under M+, most applications don't go in [1,54].
There are plenty of conventions here.
[1,*] are system files. It might be meaningful to have a directory there
for you, but then again, maybe not. [1,*] is somewhat a cesspool. :-)
[1,1] is where libraries of all kind sits, along with some other stuff.
[1,2] is where all help files are.
[1,20] is prototypes for all kind of build files.
[1,24] is build files.

In M+, only binaries that are dependent on the kernel build sits in
[1,54]. All kernel-independent binaries sits in [3,54]. Then you have
the standalone system which is in [6,54].
Also, anything ending on [*,54] are for mapped systems. [*,50] is, I
think, for unmapped systems. I have some vague memory of [*,64] also
being for something specific, but I can't recall. Much of this is
documented in some manual, which one I (of course) also don't remember.
[5,*] is traditionally where DECnet sits around.
[*,24] is build files in general, and object files.
[*,34] is where list files are placed, along with map files.

Also, in the latest version of M+, a user configurable utility UIC
exists, which is a third place to put system binaries. A little like
/usr/local/bin on RSX.

If UTLUIC is defined, $ also searches there in addition to [1,54] and
[3,54].

All UICs with a group number of 10 or less (octal) are considered system
UICs, by the way. Mostly relevant for tasks running under those UICs,
since you check protection words against the SYSTEM field for those.

[paramucho]

On Sun, 17 Feb 2013 14:43:24 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> However there is another reason as well. An AST blocks *all* other
>> ASTs, whereas an interrupt only blocks *some* other interrupts. For
>> example, a keyboard AST, which could take quite extensive processing,
>> can block a timer AST.
>
>Ah. Now, that is a very good point. Although code that spends lots of
>time in an interrupt handler is not very nice code to start with.
>But yeah, ASTs are all or nothing.

It happens when the terminal driver has to handle echo.


<snip>

>>> Maybe you've found a nice bug. There have been some bug fixes related to
>>> ASTs over the years, as far as I can remember.
>>
>> My guess is that I'm doing something naive like I did with the user
>> mode vector table for SVTK$.
>
>It should not be possible to crash RSX anyway.

I haven't seen the bug for a couple of days.

I think it disappeared when I reorganised the order of the routines
etc in my main source module.

I still have copies of the older modules to test later if indeed the
bug has gone away.

<snip>

>> I have a question. RTX.TSK itself will go into [1,54], but I'm going
>> to need a separate RSX directory to hold the RTX.TSK system files and
>> applications--would there be any problems if I just chose a default
>> directory name such as [1,64] and use that? I can make the name
>> configurable in a .INI file, but I like to have a reliable default for
>> these things.
>
>Please keep in mind that under M+, most applications don't go in [1,54].

...

Noted.

Is there a way for a task to determine whether a particular
device/unit has been mounted, and if so as a FILES11 volume or as a
foreign device and whether the task has access to the volume?

Ian

[paramucho]

On Tue, 19 Feb 2013 14:09:27 GMT, para...@hotmail.com (paramucho)
wrote:

>>>> Maybe you've found a nice bug. There have been some bug fixes related to
>>>> ASTs over the years, as far as I can remember.
>>>
>>> My guess is that I'm doing something naive like I did with the user
>>> mode vector table for SVTK$.
>>
>>It should not be possible to crash RSX anyway.
>
>I haven't seen the bug for a couple of days.

But on a ridiculous note I found an easier way to crash RSXV44 (on V11
or SimH):

> RUN MCR
OD:120716
XDT>

Ian

[Johnny Billquist]

On 2013-02-19 15:09, paramucho wrote:
> On Sun, 17 Feb 2013 14:43:24 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>> However there is another reason as well. An AST blocks *all* other
>>> ASTs, whereas an interrupt only blocks *some* other interrupts. For
>>> example, a keyboard AST, which could take quite extensive processing,
>>> can block a timer AST.
>>
>> Ah. Now, that is a very good point. Although code that spends lots of
>> time in an interrupt handler is not very nice code to start with.
>> But yeah, ASTs are all or nothing.
>
> It happens when the terminal driver has to handle echo.

That is done in the interrupt context in RT-11?

>>>> Maybe you've found a nice bug. There have been some bug fixes related to
>>>> ASTs over the years, as far as I can remember.
>>>
>>> My guess is that I'm doing something naive like I did with the user
>>> mode vector table for SVTK$.
>>
>> It should not be possible to crash RSX anyway.
>
> I haven't seen the bug for a couple of days.
>
> I think it disappeared when I reorganised the order of the routines
> etc in my main source module.
>
> I still have copies of the older modules to test later if indeed the
> bug has gone away.

It would be even more interesting to know if the bug is still there in
the latest version of RSX...

>>> I have a question. RTX.TSK itself will go into [1,54], but I'm going
>>> to need a separate RSX directory to hold the RTX.TSK system files and
>>> applications--would there be any problems if I just chose a default
>>> directory name such as [1,64] and use that? I can make the name
>>> configurable in a .INI file, but I like to have a reliable default for
>>> these things.
>>
>> Please keep in mind that under M+, most applications don't go in [1,54].
> ...
>
> Noted.
>
> Is there a way for a task to determine whether a particular
> device/unit has been mounted, and if so as a FILES11 volume or as a
> foreign device and whether the task has access to the volume?

GLUN$ gives you parts of the information, but is not really good enough
for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
I think that is M+ only.

[Johnny Billquist]

That sounds really weird... Are you sure you have a proper installation?

[paramucho]

On Thu, 21 Feb 2013 01:22:47 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>>> Ah. Now, that is a very good point. Although code that spends lots of
>>> time in an interrupt handler is not very nice code to start with.
>>> But yeah, ASTs are all or nothing.
>>
>> It happens when the terminal driver has to handle echo.
>
>That is done in the interrupt context in RT-11?

In fork context, aka system state in RT-11. It doesn't take all that
long and it's largely historical (from hard copy days).

>> I still have copies of the older modules to test later if indeed the
>> bug has gone away.
>
>It would be even more interesting to know if the bug is still there in
>the latest version of RSX...

I saw it once tonight while testing some RUST/SJ utility drivers under
RTX.TSK which I knew were going to crash (because they aren't fully
compatible with the RTX terminal interface). I think it must be
related to the terminal--it's always triggered by terminal input.

The installation is the same RSXV44 system I mentioned. I haven't
altered the configuration. If it is an "improper" installation then
that might explain both bugs. But that's the easy answer.

>>>> I have a question. RTX.TSK itself will go into [1,54], but I'm going
>>>> to need a separate RSX directory to hold the RTX.TSK system files and
>>>> applications--would there be any problems if I just chose a default
>>>> directory name such as [1,64] and use that? I can make the name
>>>> configurable in a .INI file, but I like to have a reliable default for
>>>> these things.
>>>
>>> Please keep in mind that under M+, most applications don't go in [1,54].
>> ...
>>
>> Noted.

That said, I note that RTEM.TSK resides in [1,54], probably because
it's considered a system program rather than an app.

>> Is there a way for a task to determine whether a particular
>> device/unit has been mounted, and if so as a FILES11 volume or as a
>> foreign device and whether the task has access to the volume?
>
>GLUN$ gives you parts of the information, but is not really good enough
>for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>I think that is M+ only.

I guess I could probe all known disks with ALUN$ and various QIOs and
look for error messages.

I noticed that the F11A ACP doesn't support a RENAME operation
directly but that applications have to DELETE the old name and then
ENTER a new name, attaching the existing FID to the new name. What
happens if the application aborts after the DELETE but before the
ENTER? Does the FID become an orphan?








Ian

[paramucho]

On Thu, 21 Feb 2013 01:22:47 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>>> Ah. Now, that is a very good point. Although code that spends lots of
>>> time in an interrupt handler is not very nice code to start with.
>>> But yeah, ASTs are all or nothing.
>>
>> It happens when the terminal driver has to handle echo.
>
>That is done in the interrupt context in RT-11?

In fork context, aka system state in RT-11. It doesn't take all that
long and it's largely historical (from hard copy days).

>> I still have copies of the older modules to test later if indeed the
>> bug has gone away.
>
>It would be even more interesting to know if the bug is still there in
>the latest version of RSX...

I saw it once tonight while testing some RUST/SJ utility drivers under
RTX.TSK which I knew were going to crash (because they aren't fully
compatible with the RTX terminal interface). I think it must be
related to the terminal--it's always triggered by terminal input.

The installation is the same RSXV44 system I mentioned. I haven't
altered the configuration. If it is an "improper" installation then
that might explain both bugs. But that's the easy answer.

>>>> I have a question. RTX.TSK itself will go into [1,54], but I'm going
>>>> to need a separate RSX directory to hold the RTX.TSK system files and
>>>> applications--would there be any problems if I just chose a default
>>>> directory name such as [1,64] and use that? I can make the name
>>>> configurable in a .INI file, but I like to have a reliable default for
>>>> these things.
>>>
>>> Please keep in mind that under M+, most applications don't go in [1,54].
>> ...
>>
>> Noted.

That said, I note that RTEM.TSK resides in [1,54], probably because
it's considered a system program rather than an app.

>> Is there a way for a task to determine whether a particular
>> device/unit has been mounted, and if so as a FILES11 volume or as a
>> foreign device and whether the task has access to the volume?
>
>GLUN$ gives you parts of the information, but is not really good enough
>for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>I think that is M+ only.

[Johnny Billquist]

On 2013-02-24 15:10, paramucho wrote:
> On Thu, 21 Feb 2013 01:22:47 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>>> Ah. Now, that is a very good point. Although code that spends lots of
>>>> time in an interrupt handler is not very nice code to start with.
>>>> But yeah, ASTs are all or nothing.
>>>
>>> It happens when the terminal driver has to handle echo.
>>
>> That is done in the interrupt context in RT-11?
>
> In fork context, aka system state in RT-11. It doesn't take all that
> long and it's largely historical (from hard copy days).

Oh, c'mon. I/O takes for *ever*. :-)

>>> I still have copies of the older modules to test later if indeed the
>>> bug has gone away.
>>
>> It would be even more interesting to know if the bug is still there in
>> the latest version of RSX...
>
> I saw it once tonight while testing some RUST/SJ utility drivers under
> RTX.TSK which I knew were going to crash (because they aren't fully
> compatible with the RTX terminal interface). I think it must be
> related to the terminal--it's always triggered by terminal input.
>
> The installation is the same RSXV44 system I mentioned. I haven't
> altered the configuration. If it is an "improper" installation then
> that might explain both bugs. But that's the easy answer.

Yeah. Too much unknown here. However, the terminal driver in RSX is also
maybe the most complex piece of all the system. There might be several
bugs in there that could have survived for years without anyone
noticing, since it can be configured and set up in so many different ways.

>>>>> I have a question. RTX.TSK itself will go into [1,54], but I'm going
>>>>> to need a separate RSX directory to hold the RTX.TSK system files and
>>>>> applications--would there be any problems if I just chose a default
>>>>> directory name such as [1,64] and use that? I can make the name
>>>>> configurable in a .INI file, but I like to have a reliable default for
>>>>> these things.
>>>>
>>>> Please keep in mind that under M+, most applications don't go in [1,54].
>>> ...
>>>
>>> Noted.
>
> That said, I note that RTEM.TSK resides in [1,54], probably because
> it's considered a system program rather than an app.

Uh? RTEM.TSK don't need to be anywhere in particular. I have it in
LB:[RTEM] on my system...
What made you think it must be in [1,54]?

>>> Is there a way for a task to determine whether a particular
>>> device/unit has been mounted, and if so as a FILES11 volume or as a
>>> foreign device and whether the task has access to the volume?
>>
>> GLUN$ gives you parts of the information, but is not really good enough
>> for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>> I think that is M+ only.
>
> I guess I could probe all known disks with ALUN$ and various QIOs and
> look for error messages.

Yuck! GLUN$ is atleast better than that.

> I noticed that the F11A ACP doesn't support a RENAME operation
> directly but that applications have to DELETE the old name and then
> ENTER a new name, attaching the existing FID to the new name. What
> happens if the application aborts after the DELETE but before the
> ENTER? Does the FID become an orphan?

Yes. Or you'd rather say that it comes a lost file. VFY can locate and
recover such files.

However, why remove the old one before entering the new one?
Add the new one first, and then remove the old one. Better from a
recovery point of view.

[paramucho]

On Sun, 24 Feb 2013 16:00:16 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> That said, I note that RTEM.TSK resides in [1,54], probably because
>> it's considered a system program rather than an app.
>
>Uh? RTEM.TSK don't need to be anywhere in particular. I have it in
>LB:[RTEM] on my system...
>What made you think it must be in [1,54]?

That's not what I said, but I did forget to mention the source: it's
the RTEM documentation kit that describes RTEM.TSK as residing in
[1,54]. The installation procedure describes the copy operation as
follows (page 2.5):

PIP DR0:[1,54]RTEM.TSK/...=DL1:[277,54]RTEM.TSK

An earlier section states the locations as follows (page 1.1).
("sysuic" is not detailed).

RTEM.TSK LB:[sysuic]
RT11SH.SYS LB:[1,1]

>>>> Is there a way for a task to determine whether a particular
>>>> device/unit has been mounted, and if so as a FILES11 volume or as a
>>>> foreign device and whether the task has access to the volume?
>>>
>>> GLUN$ gives you parts of the information, but is not really good enough
>>> for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>>> I think that is M+ only.
>>
>> I guess I could probe all known disks with ALUN$ and various QIOs and
>> look for error messages.
>
>Yuck! GLUN$ is atleast better than that.

GLUN$ would be included in the party. Throw everything at the system
and see if it falls over and whether it can get back up again :-)

>> I noticed that the F11A ACP doesn't support a RENAME operation
>> directly but that applications have to DELETE the old name and then
>> ENTER a new name, attaching the existing FID to the new name. What
>> happens if the application aborts after the DELETE but before the
>> ENTER? Does the FID become an orphan?
>
>Yes. Or you'd rather say that it comes a lost file. VFY can locate and
>recover such files.
>
>However, why remove the old one before entering the new one?
>Add the new one first, and then remove the old one. Better from a
>recovery point of view.

I'm reporting what PIP actually does, and PIP does the delete first.
Likewise, the RSX documentation (IO Operations Manual, ACP appendix)
says to delete then enter. Perhaps it has something to do with the
identification area of the file header (i.e. I.FNAM and I.FTYP).

Here's a V11 trace of a PIP rename (with some ALUNs/GLUNs deleted)

DCL> rename g.g h.h
26456u 326 alun lun=4 dev=[SY]
20426u 15370 qiow fun=11=(fna) lun=4 efn=40 isb=15420
p1=0 p2=0 p3=0 p4=0 p5=0 p6=1514
nam=[DL0:001054.DIR] fid=0/0 did=4/4
26456u 334 alun lun=3 dev=[DL]
20426u 15370 qiow fun=11=(fna) lun=3 efn=40 isb=15420

p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654

nam=[DL0:G.G] fid=0/0 did=22/1
20426u 15370 qiow fun=13=(rna) lun=3 efn=40 isb=15420

p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654

nam=[DL0:G.G] fid=607/11 did=22/1
26456u 346 alun lun=4 dev=[DL]
20426u 15370 qiow fun=14=(ena) lun=4 efn=40 isb=15420
p1=0 p2=0 p3=0 p4=0 p5=0 p6=1514
nam=[DL0:H.H] fid=607/11 did=22/1

I'm getting a bit more skilled with RSX so I managed to find the
location of the intermittent crash. It's the CRASH at 100$ in
CORAL.MAC, which points to a corruption of the dynamic memory
structures detected during DEAC1. I'll put a breakpoint at the
location to see if I can get more detail. It seems only to happen when
I use KEYPAD.SAV (a KED replacement) in RTX. There is no access to RSX
disks, so I think it must be tied to the terminal, or perhaps ASTs in
general.


Ian

[paramucho]

On Sun, 24 Feb 2013 16:00:16 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> That said, I note that RTEM.TSK resides in [1,54], probably because
>> it's considered a system program rather than an app.
>
>Uh? RTEM.TSK don't need to be anywhere in particular. I have it in
>LB:[RTEM] on my system...
>What made you think it must be in [1,54]?

That's not what I said, but I did forget to mention the source: it's
the RTEM documentation kit that describes RTEM.TSK as residing in
[1,54]. The installation procedure describes the copy operation as
follows (page 2.5):

PIP DR0:[1,54]RTEM.TSK/...=DL1:[277,54]RTEM.TSK

An earlier section states the locations as follows (page 1.1).
("sysuic" is not detailed).

RTEM.TSK LB:[sysuic]
RT11SH.SYS LB:[1,1]

>>>> Is there a way for a task to determine whether a particular
>>>> device/unit has been mounted, and if so as a FILES11 volume or as a
>>>> foreign device and whether the task has access to the volume?
>>>
>>> GLUN$ gives you parts of the information, but is not really good enough
>>> for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>>> I think that is M+ only.
>>
>> I guess I could probe all known disks with ALUN$ and various QIOs and
>> look for error messages.
>
>Yuck! GLUN$ is atleast better than that.

GLUN$ would be included in the party. Throw everything at the system
and see if it falls over and whether it can get back up again :-)

>> I noticed that the F11A ACP doesn't support a RENAME operation
>> directly but that applications have to DELETE the old name and then
>> ENTER a new name, attaching the existing FID to the new name. What
>> happens if the application aborts after the DELETE but before the
>> ENTER? Does the FID become an orphan?
>
>Yes. Or you'd rather say that it comes a lost file. VFY can locate and
>recover such files.
>
>However, why remove the old one before entering the new one?
>Add the new one first, and then remove the old one. Better from a
>recovery point of view.

[Johnny Billquist]

On 2013-03-06 16:33, paramucho wrote:
> On Sun, 24 Feb 2013 16:00:16 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>>> That said, I note that RTEM.TSK resides in [1,54], probably because
>>> it's considered a system program rather than an app.
>>
>> Uh? RTEM.TSK don't need to be anywhere in particular. I have it in
>> LB:[RTEM] on my system...
>> What made you think it must be in [1,54]?
>
> That's not what I said, but I did forget to mention the source: it's
> the RTEM documentation kit that describes RTEM.TSK as residing in
> [1,54]. The installation procedure describes the copy operation as
> follows (page 2.5):
>
> PIP DR0:[1,54]RTEM.TSK/...=DL1:[277,54]RTEM.TSK
>
> An earlier section states the locations as follows (page 1.1).
> ("sysuic" is not detailed).
>
> RTEM.TSK LB:[sysuic]
> RT11SH.SYS LB:[1,1]

Oh! Ah. Yes...
The reason for that is probably because RTEM was only ever intended for
(or maybe even officially supported) on 11M, where system programs
always sits in [1,54].
But that is just a convention. You can have the binary anywhere and it
works just as well. And if you install it, you will not even be aware of
where the binary actually resides in the file system.

To be even more clear: SYSUIC is an actual value in RSX. On a mapped 11M
system, it is normally [1,54], but under some circumstances it might be
something else.

RT11SH.SYS on the other hand is by default expected to be found in LB:[1,1].

The moving of system independent tasks only came about in M+. Before
that there was only SYSUIC, and everything was expected to sit there.

>>>>> Is there a way for a task to determine whether a particular
>>>>> device/unit has been mounted, and if so as a FILES11 volume or as a
>>>>> foreign device and whether the task has access to the volume?
>>>>
>>>> GLUN$ gives you parts of the information, but is not really good enough
>>>> for that purpose. What you need is GIN$, and the GI.DEV subfunction. But
>>>> I think that is M+ only.
>>>
>>> I guess I could probe all known disks with ALUN$ and various QIOs and
>>> look for error messages.
>>
>> Yuck! GLUN$ is atleast better than that.
>
> GLUN$ would be included in the party. Throw everything at the system
> and see if it falls over and whether it can get back up again :-)

:-)

>>> I noticed that the F11A ACP doesn't support a RENAME operation
>>> directly but that applications have to DELETE the old name and then
>>> ENTER a new name, attaching the existing FID to the new name. What
>>> happens if the application aborts after the DELETE but before the
>>> ENTER? Does the FID become an orphan?
>>
>> Yes. Or you'd rather say that it comes a lost file. VFY can locate and
>> recover such files.
>>
>> However, why remove the old one before entering the new one?
>> Add the new one first, and then remove the old one. Better from a
>> recovery point of view.
>
> I'm reporting what PIP actually does, and PIP does the delete first.

Ok. But either way will work.

> Likewise, the RSX documentation (IO Operations Manual, ACP appendix)
> says to delete then enter. Perhaps it has something to do with the
> identification area of the file header (i.e. I.FNAM and I.FTYP).

No. There is nothing in there that are affected. A rename don't even
touch the file header. It's just a question of adding/removing entries
in the directory.
(This implies a problem in the RSX system, however. There is no
information in a file about which directory it was expected to sit in,
so if it gets lost, VFY can not properly recover, but instead places all
lost and found files in [1,3]. VMS did add a backpointer in the file
header for ODS-2, if I remember right.)

> Here's a V11 trace of a PIP rename (with some ALUNs/GLUNs deleted)
>
> DCL> rename g.g h.h
> 26456u 326 alun lun=4 dev=[SY]
> 20426u 15370 qiow fun=11=(fna) lun=4 efn=40 isb=15420
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1514
> nam=[DL0:001054.DIR] fid=0/0 did=4/4
> 26456u 334 alun lun=3 dev=[DL]
> 20426u 15370 qiow fun=11=(fna) lun=3 efn=40 isb=15420
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
> nam=[DL0:G.G] fid=0/0 did=22/1
> 20426u 15370 qiow fun=13=(rna) lun=3 efn=40 isb=15420
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1654
> nam=[DL0:G.G] fid=607/11 did=22/1
> 26456u 346 alun lun=4 dev=[DL]
> 20426u 15370 qiow fun=14=(ena) lun=4 efn=40 isb=15420
> p1=0 p2=0 p3=0 p4=0 p5=0 p6=1514
> nam=[DL0:H.H] fid=607/11 did=22/1

Pretty straight forward...

> I'm getting a bit more skilled with RSX so I managed to find the
> location of the intermittent crash. It's the CRASH at 100$ in
> CORAL.MAC, which points to a corruption of the dynamic memory
> structures detected during DEAC1. I'll put a breakpoint at the
> location to see if I can get more detail. It seems only to happen when
> I use KEYPAD.SAV (a KED replacement) in RTX. There is no access to RSX
> disks, so I think it must be tied to the terminal, or perhaps ASTs in
> general.

Most likely it's actually a call to $DEACB, and not $DEAC1. But anyway...
I seem to remember that there might be an issue if you are sending
characters at a very high rate into RSX. The terminal device driver do
not handle that correctly, but it's not something ever noted by DEC,
since you can't physically produce characters at such rate on real
hardware. But it has been noted in simulators... Typically things like
function keys, which sends several characters are the thing that trigger it.
Could it be something related to that?

[paramucho]

On Thu, 07 Mar 2013 00:51:26 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>RT11SH.SYS on the other hand is by default expected to be found in LB:[1,1].
>
>The moving of system independent tasks only came about in M+. Before
>that there was only SYSUIC, and everything was expected to sit there.

What I need is a simple default location, so I guess I'll use [1,1].
<snip>

>> I'm getting a bit more skilled with RSX so I managed to find the
>> location of the intermittent crash. It's the CRASH at 100$ in
>> CORAL.MAC, which points to a corruption of the dynamic memory
>> structures detected during DEAC1. I'll put a breakpoint at the
>> location to see if I can get more detail. It seems only to happen when
>> I use KEYPAD.SAV (a KED replacement) in RTX. There is no access to RSX
>> disks, so I think it must be tied to the terminal, or perhaps ASTs in
>> general.
>
>Most likely it's actually a call to $DEACB, and not $DEAC1. But anyway...
>I seem to remember that there might be an issue if you are sending
>characters at a very high rate into RSX. The terminal device driver do
>not handle that correctly, but it's not something ever noted by DEC,
>since you can't physically produce characters at such rate on real
>hardware. But it has been noted in simulators... Typically things like
>function keys, which sends several characters are the thing that trigger it.
>Could it be something related to that?

V11 has per-device interrupt latency delays to deal with that kind of
situation (as do E11 and SimH). I've since reduced the latency to zero
for the terminal to check worst-case, but it hasn't resulted in more
problems. I'll keep looking at that option though because it does seem
to happen when I've just typed something--although typing tends to
activate the process.

Meanwhile the major functionality of RTX is now up under RSX-11M with
access to RSX directories and devices for RT-11 programs. The wildcard
directory stuff ended up being fairly simple, but rather expensive in
terms of I/O (because of version numbers). There are many minor issues
still to address.

Is there anyway for a task to determine the directory from which the
task was run? I can find the device and unit using "OV", but I can't
see anyway to work out the directory. I want to use this information
to automatically find related files--for example, when RTX.TSK is
activated I want to be able to read "RTX.INI" from the same directory
and to access "RTX.DSK" likewise from the same directory.


Ian

[Johnny Billquist]

On 2013-03-20 11:15, paramucho wrote:
> On Thu, 07 Mar 2013 00:51:26 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>
>
>> RT11SH.SYS on the other hand is by default expected to be found in LB:[1,1].
>>
>> The moving of system independent tasks only came about in M+. Before
>> that there was only SYSUIC, and everything was expected to sit there.
>
> What I need is a simple default location, so I guess I'll use [1,1].
> <snip>

For things similar to RT11SH.SYS, [1,1] is a pretty reasonable place.

> Meanwhile the major functionality of RTX is now up under RSX-11M with
> access to RSX directories and devices for RT-11 programs. The wildcard
> directory stuff ended up being fairly simple, but rather expensive in
> terms of I/O (because of version numbers). There are many minor issues
> still to address.

Yeah. To figure out the latest version, you need to scan through the
whole directory.
You can do that more efficiently than doing a QIO for each file just to
find the next one, though.
(Although the QIO function makes it more transparent.)

> Is there anyway for a task to determine the directory from which the
> task was run? I can find the device and unit using "OV", but I can't
> see anyway to work out the directory. I want to use this information
> to automatically find related files--for example, when RTX.TSK is
> activated I want to be able to read "RTX.INI" from the same directory
> and to access "RTX.DSK" likewise from the same directory.

Unfortunately, the answer is "no". Running a task that is installed
don't have a directory associated with it. Installed tasks just "are".

Running not installed tasks, such as when you do "RUN FOO.TSK" is
actually a two-stage rocket. First INS will install the task for you,
and then you will run an installed task. Now go back to what I wrote
about installed tasks...
This two-stage rocket is called "flying install". Tasks installed this
way are marked for automatic removal when they terminate. And that is
the only way non-privileged terminals can install tasks.

The bottom line is also that RSX can only run installed tasks.

[Jerome H. Fine]

>paramucho wrote:

>Is there anyway for a task to determine the directory from which the
>task was run? I can find the device and unit using "OV", but I can't
>see anyway to work out the directory. I want to use this information
>to automatically find related files--for example, when RTX.TSK is
>activated I want to be able to read "RTX.INI" from the same directory
>and to access "RTX.DSK" likewise from the same directory.
>

I don't think that you are asking about running under RT-11.
Since I don't know about RSX-11 internals, I will defer to
Johnny.

Under RT-11, any program which runs using overlays
has access via the .CStatus EMT request to the physical
device name where the program is located. Since any
program can be declared to use overlays by setting the
correct bit in the $Jsw location in the program image
file - location 44 octal - all programs under RT-11
are able to locate and read the entry for their file label
on the disk drive where the file was first read when
the program was started. This means that even if a
file under RT-11 is RENAMEd and copied to a
different directory, that new file name and location
can be determined by the program. Both DIR.SAV
and PIP.SAV do this all the time, although not to
determine their own file name or location.

Jerome Fine

[Johnny Billquist]

On 2013-03-20 14:01, Johnny Billquist wrote:
> On 2013-03-20 11:15, paramucho wrote:
>> On Thu, 07 Mar 2013 00:51:26 +0100, Johnny Billquist <b...@softjar.se>
>> wrote:
>>
>>
>>> RT11SH.SYS on the other hand is by default expected to be found in
>>> LB:[1,1].
>>>
>>> The moving of system independent tasks only came about in M+. Before
>>> that there was only SYSUIC, and everything was expected to sit there.
>>
>> What I need is a simple default location, so I guess I'll use [1,1].
>> <snip>
>
> For things similar to RT11SH.SYS, [1,1] is a pretty reasonable place.
>

>> Is there anyway for a task to determine the directory from which the
>> task was run? I can find the device and unit using "OV", but I can't
>> see anyway to work out the directory. I want to use this information
>> to automatically find related files--for example, when RTX.TSK is
>> activated I want to be able to read "RTX.INI" from the same directory
>> and to access "RTX.DSK" likewise from the same directory.
>
> Unfortunately, the answer is "no". Running a task that is installed
> don't have a directory associated with it. Installed tasks just "are".

By the way, depending on what is in those files, you might want to
reconsider.
If it is content that different users might want to configure
differently, then you should either try to figure out there login
directory, or possibly just use the current directory.
And if we're talking about system global configuration files and
whatnot, then the common solution is to use a known directory. For
example [1,1], but there are many directories that might make sense,
depending on what it is. Also, you could create your own directory that
you use. No need to necessarily use any already existing directory.

Johnny

[paramucho]

On Wed, 20 Mar 2013 10:15:49 GMT, para...@hotmail.com (paramucho)
wrote:

>O

>>> I'm getting a bit more skilled with RSX so I managed to find the
>>> location of the intermittent crash. It's the CRASH at 100$ in
>>> CORAL.MAC, which points to a corruption of the dynamic memory
>>> structures detected during DEAC1. I'll put a breakpoint at the
>>> location to see if I can get more detail. It seems only to happen when
>>> I use KEYPAD.SAV (a KED replacement) in RTX. There is no access to RSX
>>> disks, so I think it must be tied to the terminal, or perhaps ASTs in
>>> general.
>>
>>Most likely it's actually a call to $DEACB, and not $DEAC1. But anyway...
>>I seem to remember that there might be an issue if you are sending
>>characters at a very high rate into RSX. The terminal device driver do
>>not handle that correctly, but it's not something ever noted by DEC,
>>since you can't physically produce characters at such rate on real
>>hardware. But it has been noted in simulators... Typically things like
>>function keys, which sends several characters are the thing that trigger it.
>>Could it be something related to that?
>
>V11 has per-device interrupt latency delays to deal with that kind of
>situation (as do E11 and SimH). I've since reduced the latency to zero
>for the terminal to check worst-case, but it hasn't resulted in more
>problems. I'll keep looking at that option though because it does seem
>to happen when I've just typed something--although typing tends to
>activate the process.

On reflection, if it was a latency issue then I'd expect it to occur
in my usage of RSX under V11 when I'm not running RTX, but it never
crashes in that context, only when RTX is running. But it definitely
seems to be triggered by the keyboard.

Over the weekend the crash started to occur more frequently again. I
still don't have an RSX crash dump setup, but I have added "machine
save" and "machine restore" (including the instruction history) to the
V11 debugger so that I am now saving crashed system images for later
perusal.

Why the bug has returned now is another question. It might be
positional (i.e. where particular bits of code sit in memory) or it
might be some of the clean-up work I've been doing on the basic system
calls that RTX emits.

I really need to configure a different RSX system image and get M+ up
for testing. I'm at the point where I could test under SimH and E11 if
I found the time.



Ian

[paramucho]

On Wed, 20 Mar 2013 22:42:46 +0100, Johnny Billquist <b...@softjar.se>

It is configurable (although I don't expect to find many users :-),
but I like simple, sensible defaults so that no setup is required most
of the time. I haven't found any information about standard
directories for tasks etc other than [1,1] and [1,54].

RTX is more or less functional (I can assemble RTX with all the source
files and binaries in F11A directories) and I'm adding some bells and
whistles while I bed it down. I wrote a couple of apps to call MCR and
DCL from within RTX, but I can't do things like DCL MOUNT because of
insufficient privilege. Is there some way around this? I've never
worked out how to create a privileged image/user etc.



Ian

[Johnny Billquist]

Let's see, from the top of my head:
[1,1] System libraries and files of general use.
[1,2] System help files, system command files
[1,3] Recovered files
[1,4] System console logs
[1,6] Errorlog files, and also FAL log files
[1,54] System executables (system dependent)
[2,54] Baseline system
[3,54] System executables (system independent, M+ only)
[6,54] Standalone system
[*,10] Sources
[*,24] Command files to build sources
[*,34] Listings from builds
[*,54] Destination task files
[11,*] Kernel and device drivers
[12,*] MCR and related
[13,*] FCP
[14,*] RMD
[15,*] Executive utilities
[16,*] Multiuser utilities
[17,*] ERRLOG
[20,*] File system related
[22,*] MTAACP
[23,*] DCL
[24,*] TDX
[25,*] QMG
[26,*] BPR
[27,*] CON,HRC
[30,*] MAC
[31,*] TKB
[32,*] PIP
[33,*] FLX
[34,*] VFY
[35,*] DMP
[36,*] DSC
[37,*] EDI
[40,*] SLP
[42,*] LBR
[45,*] K-series
[46,*] PRT
[47,*] ODT
[50,*] FCS
[55,*] SYSLIB
[57,*] ZAP
[60,*] PIPUTL
[61,*] RSXMAC (RSX macros)
[62,*] BAD
[65,*] CRF
[70,*] VMR
[74,*] BRU
[75,*] RCT
[77,*] ISC,ICP
[103,*] RPT
[104,*] ERRLOG control files
[107,*] CMP
[111,*] PAT
[112,*] FMT
[113,*] IOX
[117,*] CDA
[120,*] CRP
[121,*] LPP
[123,*] VCP
[125,*] Shadow recording
[126,*] Accounting
[200,*] SYSGEN

Although not as official, [5,*] is usually where DECnet for the running
system resides.

(Actually, that became a little more than the top of my head, but there
is more documentation somewhere in the manuals, that we could check if
you want to.)

> RTX is more or less functional (I can assemble RTX with all the source
> files and binaries in F11A directories) and I'm adding some bells and
> whistles while I bed it down. I wrote a couple of apps to call MCR and
> DCL from within RTX, but I can't do things like DCL MOUNT because of
> insufficient privilege. Is there some way around this? I've never
> worked out how to create a privileged image/user etc.

First of all, in which way is things like mount failing? It should
normally not try to run ...MOU yourself, but instead call MCR with the
command line, and MCR will invoke MOUNT in the proper way. (Or call DCL,
same deal.)
However, MOUNT expects you to either mount a volume foreign, or else
provide the disk label. You cannot use the /OVR switch without being
privileged.

Also, "privilege" in RSX can be a bit confusing before you get the grasp
of things. There are several independent things called privilege.
First of all, your terminal have a "privilege" attribute. This is
probably the most important kind of privilege there is. All kind of
commands that looks for "privilege" is looking at this terminal attribute.
Second is the file system (and regions), which looks at UIC, and any UIC
with a group number of 10 or less is considered SYSTEM, and goes under
that protection mask.
Third is task privilege. A task can be privileged. This decides whether
the task can do some system calls or not. Things like aborting a task
running at another terminal requires that the task is privileged.

That's the three things we have to play with.
In order to run any task, it needs to be installed. In general, only
privileged terminals can install tasks. There is a special variant of
install that can be done, which is a flying install, where the task is
removed again when it finishes. This is what "RUN" do. And this is the
only way non-privileged terminals can install tasks. One additional
restriction on this is that non-privileged terminals can only install
tasks that are non-privileged.

So, for a non-privileged terminal to run a privileged task, it must
already have been installed by a privileged terminal.
At this point, it is left to the task itself to decide whether or not to
allow some operations. So, MOU for example, checks if the terminal is
privileged or not, and refuses certain switches if the terminal is not
privileged. However, if you try to run the MOUNT.TSK binary yourself,
you cannot if you are not a privileged terminal, as the task have the
privileged attribute set.

A task have the privileged attribute set if, when task built, you give
the /PR:n switch. The :n can have three values.
0 - Privileged task with no special mapping
4 - Privileged task mapped to the kernel in a 16K kernel.
5 - Privileged task mapped to the kernel in a 20K kernel.
5 is the default.

The /AC:n switch also implies the /PR switch.

Finally, tasks that are installed in the form of ...xxx or xxx$$$ are so
called prototype tasks, and cannot be run (under M+). Instead they are
just templates used by MCR when you give the command, and a copy is
created which is deleted when the task finishes.

Sorry for the long-winded reply, but maybe it helps. :-)

[Johnny Billquist]

On 2013-04-14 20:28, Johnny Billquist wrote:
> Sorry for the long-winded reply, but maybe it helps. :-)

And of course I forgot one thing. :-)
When you log in, the login process is privileged, and at the start the
terminal is privileged. As a step in the login process, if the group
number of your UIC is >10, your terminal will be set to non-privileged
at login time.

So, only accounts in groups 10 and lower will have privileged terminals
when they log in.

And at boot time, the console terminal is privileged. (Otherwise system
startup would become hard...)

Johnny