RMS-11
Johnny Billquist
they differ.
I have a tricky problem. I've written a device driver that pretends to
look like a file system without using any ACP. It implements most
functions an ACP normally implement. It also have some "odd" attributes
set on the device to represent both what it actually is, and also to
make FCS do "the right thing".
So, yes, using FCS, I can access this device just like any other,
including opening files and so on... However, RMS-11 is not so
cooperative, and I guess it means that I'm either not implementing some
ACP function in enough detail to make RMS-11 happy, or else some device
attribute it not set right, causing RMS-11 to treat the whole thing in a
way that is too restricted, compared to FCS, in which case I want to
figure out exactly how to set attributes to make RMS-11 do the right
thing as well.
And just to explain what I'm doing in a little more detail:
I've actually done this for two devices. The first is the DOS device
presented by E11 and other emulators. It's a device that gives access to
the host file system.
The second device is actually TCP/IP. I can use normal tools and FCS
functions to access the internet, just as easy as any other file. But
not so, using RMS... :-(
As an example:
.pip ti:=tc:"130.238.19.25";21
220- ===============================================================
220- = Welcome to the Update Computer Club FTP archives! =
220- ===============================================================
220-
220- This server is maintained by the computer club Update at
220- Uppsala University in Uppsala, Sweden.
220-
220- You can find all the good stuff in the /pub directory.
220-
220- Please be advised that the club provides this service without
220- any guarantees, and we take no responsibility for any harm that
220- may come to you or your system from the use of this server, or
220- files obtained from this server.
220-
220- We do, however, try to ensure that everything here is correct.
220- If you have problems with the server, please contact the
220- FTP administrator ftp...@Update.UU.SE.
220-
220
PIP -- I/O error on input file
TC0:[IPLIB]130238019.025;21 -- Timeout on request
.
Now, it would be awesome if I could make this play using RMS as well,
since then I could easily write servers using BASIC+2 or other
languages. FORTRAN 77 as well as C do also have FCS interfaces, so I can
already use those, assuming I'm happy with limiting myself to FCS. But I
want it all (of course). So - anyone who might be able to help?
(And no, the TCP/IP is not available for distribution yet, but might be
in the future, depending on interest and so on...)
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
Hein RMS van den Heuvel
> Does anyone have sources to RMS-11 V2.0. Specifically for RSX, in case
> they differ.
> So, yes, using FCS, I can access this device just like any other,
> including opening files and so on... However, RMS-11 is not so
> cooperative, and I guess it means that I'm either not implementing some
> ACP function in enough detail to make RMS-11 happy
from the file header.
Are those mimicked?
VMS - RMS, when wildcards are present reads the directory itself
versus letting the ACP find the file. Would that have been the same
for RMS-11?
Is there are error code returned at all ?
Can you single step the RMS code... for a while?
Anything of use in appendix F of the IO Operations manual where the
expected disk structure is explained?
http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V3.2_Jun79/5A_FileMgmt_IO/AA-2515D-TC_RSX-11M_V3.2_IO_Operations_Ref_Man_Jun79.pdf
also...
http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V3.2_Jun79/5A_FileMgmt_IO/AA-H269A-TC_RSX-11M_IO_Drivers_Ref_Man_May79.pdf
Good luck!
Hein
Johnny Billquist
> On Sep 6, 5:49 pm, Johnny Billquist<b...@softjar.se> wrote:
>> Does anyone have sources to RMS-11 V2.0. Specifically for RSX, in case
>> they differ.
>
> RMS-11? RSX? Sources? Microfiche? Seriously !? Interesting hobby!
We all have our quirks. :-)
>> So, yes, using FCS, I can access this device just like any other,
>> including opening files and so on... However, RMS-11 is not so
>> cooperative, and I guess it means that I'm either not implementing some
>> ACP function in enough detail to make RMS-11 happy
>
> Well, RMS-11 uses 18 bytes more than FCS in the USER FILE ATTRIBUTES
> from the file header.
Well, yes and no. RMS uses all 16 words (32 bytes) of the file header
for some of the more complex types of files (index files to be precise),
but for plain text files, they just use the same 7 words that FCS use,
and nothing more.
> Are those mimicked?
Yes. Of course. :-)
However, it don't help, as RMS never even calls my device driver. That
is my problem. It decides that it don't need to, and just do an ALUN$
and then it's done and happy.
> VMS - RMS, when wildcards are present reads the directory itself
> versus letting the ACP find the file. Would that have been the same
> for RMS-11?
Yes. Since ODS don't really know what a directory is. All ODS knows
about are file IDs. In RSX this means that even finding a file without
wildcards means that RMS (or FCS) needs to read the directory itself.
Not sure how VMS do... I would think it worked the same way...
But that is for disks. For tapes for instance, it's another deal. There
is a special I/O function for finding filenames matching the FNB for
tapes. Even with wildcarding, although the ACP wildcarding is primitive,
and the library have to implement the more sophisticated details itself.
And then you have record type devices. And this is part of what my
questions aims at: what to make the device look like to make RMS call my
device driver, and with which arguments it then actually do get called.
> Is there are error code returned at all ?
In RMS? With the current implementation, FCS calls the device driver to
get a file id, based on a FNB. RMS claims to open the file without
calling the device driver at all. So it does not give any error.
However, trying to do I/O after that, means that my TCP/IP gives an
error, since there is no connection open on that LUN.
> Can you single step the RMS code... for a while?
I've done it some, and it's tedious and complex. RMS is not a small
library...
> Anything of use in appendix F of the IO Operations manual where the
> expected disk structure is explained?
I am not trying to emulate a disk. That would imply a lot more things
that I'd have to implement, not forgetting that disks do not allow
foreign file specifications, which means I cannot give nice IP
addresses, if I were to implement this as a disk.
> http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V3.2_Jun79/5A_FileMgmt_IO/AA-2515D-TC_RSX-11M_V3.2_IO_Operations_Ref_Man_Jun79.pdf
>
> also...
>
> http://www.bitsavers.org/pdf/dec/pdp11/rsx11/RSX11M_V3.2_Jun79/5A_FileMgmt_IO/AA-H269A-TC_RSX-11M_IO_Drivers_Ref_Man_May79.pdf
You know, the newest RSX-11M-PLUS V4.6 manuals are also online at the
same site. ;-)
> Good luck!
> Hein
Thanks.
Johnny
paramucho
wrote:
>In RMS? With the current implementation, FCS calls the device driver to
>get a file id, based on a FNB. RMS claims to open the file without
>calling the device driver at all. So it does not give any error.
>However, trying to do I/O after that, means that my TCP/IP gives an
>error, since there is no connection open on that LUN.
>
>> Can you single step the RMS code... for a while?
>
>I've done it some, and it's tedious and complex. RMS is not a small
>library...
Do you have a simple stand-alone RMS test app that demonstrates the
problem? I have RSX-11M 4.4 and I also do testing in RUST/XM using an
RSX AME (which doesn't support PLAS and only has really basic support
for loadable libraries).
Ian
Johnny Billquist
Yes, I have an extremely short program that demonstrates the problem.
However, it isn't of any use to anyone else, since you also need my
TCP/IP to test this.
It is a question of RMS reacts/behaves with my device/or with devices
with different attributes. What it does for a normal disk device is
known, but I do not want to look like a disk, for reasons explained.
:-)
However, if you want to try and understand anything, you are welcome to
log into my development system and step through RMS in there. :-)
(It's Mim.Update.UU.SE, guest/guest)
Johnny
paramucho
wrote:
>On 2011-09-08 08.16, paramucho wrote:
>> On Wed, 07 Sep 2011 22:06:38 +0200, Johnny Billquist<b...@softjar.se>
>> wrote:
>>
>>
>>> In RMS? With the current implementation, FCS calls the device driver to
>>> get a file id, based on a FNB. RMS claims to open the file without
>>> calling the device driver at all. So it does not give any error.
>>> However, trying to do I/O after that, means that my TCP/IP gives an
>>> error, since there is no connection open on that LUN.
>>>
>>>> Can you single step the RMS code... for a while?
>>>
>>> I've done it some, and it's tedious and complex. RMS is not a small
>>> library...
>>
>> I think I'm starting to understand the problem.
>>
>> Do you have a simple stand-alone RMS test app that demonstrates the
>> problem? I have RSX-11M 4.4 and I also do testing in RUST/XM using an
>> RSX AME (which doesn't support PLAS and only has really basic support
>> for loadable libraries).
>
>Yes, I have an extremely short program that demonstrates the problem.
>However, it isn't of any use to anyone else, since you also need my
>TCP/IP to test this.
>It is a question of RMS reacts/behaves with my device/or with devices
>with different attributes.
All I need to know about your device should be it's unit
characteristics (record oriented FD.REC etc). That's what RMS will
know about your device (from GLUN). I should be able to fudge the rest
of the details to run a simple test program.
I have some tools which let me look at the behavior of apps and play
around with the environment. The first is the RUST RSX AME directive
trace. Here's an example trace using RSX PIP:
. mcr pip
PIP> sy:a.a=tt:aaaaaaa.aaa
...
26456 alun lun=3 dev=TT:
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
20426 qiow (att) fun=3 mod=0 lun=3 efn=40 pri=0 isb=36620 ast=0
p1=0 p2=0 p3=0 p4=0 p5=0 p6=0
26456 alun lun=4 dev=SY:
26620 glun lun=4 buf=15370
26456 alun lun=4 dev=SY:
26620 glun lun=4 buf=15370
20426 qiow (cre) fun=24 mod=0 lun=4 efn=40 pri=0 isb=15420 ast=0
p1=1514 p2=342 p3=0 p4=0 p5=0 p6=0
fid=a.a
20426 qiow (ena) fun=14 mod=0 lun=4 efn=40 pri=0 isb=15420 ast=0
p1=0 p2=0 p3=0 p4=0 p5=0 p6=1514
fid=a.a nam=a.a;0 sta=100206 nxt=0
did=001004.dir dev=SY:
20426 qiow (ace) fun=17 mod=0 lun=4 efn=40 pri=0 isb=15420 ast=0
p1=1514 p2=334 p3=0 p4=0 p5=101400 p6=0
...
Using trace I can look at the behavior if different device
characteristics settings, and I can locate the point at which RMS
looks at the settings (GLUN).
The RUST emulator debugger stores the last few hundred instructions so
it's simple to walk back through code and I can use WATCH to track
access to specific pieces of data (such as the unit characteristics).
If I need anything else I just modify the emulator.
My guess is that RMS is going to need a patch since you want your
device to look like two different sorts of device to it.
> What it does for a normal disk device is
>known, but I do not want to look like a disk, for reasons explained.
>
>:-)
I'm not thinking about disks!
>However, if you want to try and understand anything, you are welcome to
>log into my development system and step through RMS in there. :-)
>(It's Mim.Update.UU.SE, guest/guest)
I successfully logged in (after I remembered how HELLO works) and I
managed to look around, but I couldn't see any test programs.
Ian
Johnny Billquist
So, to answer your question, currently the characteristics are set as:
.WORD DV.SQD!DV.SDI!DV.DIR!DV.MNT!DV.REC ; U.CW1
and with that, I get FCS to:
1) Allow foreign filenames (by the combination of DV.SQD and DV.SDI).
2) FCS does not try to do directory lookups (DV.SDI)
3) Call the driver for IO.ENA/IO.FNA/IO.RNA (DV.DIR)
(If the file is to be created, IO.ENA is called, if it's open for
read, then IO.FNA is called, I don't really care about IO.RNA).
This step allows me to do parsing of the filename block and get a
File ID, which is used as an IP address and a port number.
4) Call the driver with IO.ACR/IO.ACE/IO.ACW to actually open the
socket. This call only have a file id as the argument, and it's only
called if DV.MNT is set.
DV.REC is good to have since otherwise FCS will think that this is a
tape device, and will do blocking/deblocking of I/O, as well as expect
ANSI "D" type records. Without DV.REC, FCS will also call the driver
with IO.CRE to create the file. That would not be a problem though, as I
can just ignore it.
Some of these flags, I could consider fooling around with, if it would
get RMS to act the way I want.
Like I said, what I'd like, is calls with IO.FNA/IO.ENA and IO.ACx from
RMS as well.
That said, I might be able to work around this by just using a small
macro routine to complete the opening when using RMS, and then use the
normal routines for the rest of it....
> I have some tools which let me look at the behavior of apps and play
> around with the environment. The first is the RUST RSX AME directive
> trace. Here's an example trace using RSX PIP:
Hey, nice!
What is RUST though? I know I've seen the name, but I can't remember
right now.
> Using trace I can look at the behavior if different device
> characteristics settings, and I can locate the point at which RMS
> looks at the settings (GLUN).
> The RUST emulator debugger stores the last few hundred instructions so
> it's simple to walk back through code and I can use WATCH to track
> access to specific pieces of data (such as the unit characteristics).
> If I need anything else I just modify the emulator.
>
> My guess is that RMS is going to need a patch since you want your
> device to look like two different sorts of device to it.
work around in that case. But I don't know for sure, so any help is
appreciated.
>> However, if you want to try and understand anything, you are welcome to
>> log into my development system and step through RMS in there. :-)
>> (It's Mim.Update.UU.SE, guest/guest)
>
> I successfully logged in (after I remembered how HELLO works) and I
> managed to look around, but I couldn't see any test programs.
Johnny
Bob Koehler
>
> Yes. Since ODS don't really know what a directory is. All ODS knows
> about are file IDs. In RSX this means that even finding a file without
> wildcards means that RMS (or FCS) needs to read the directory itself.
> Not sure how VMS do... I would think it worked the same way...
Same. RMS knows about what is inside files, the XQP (or theACP) knows
what is going on outside. RMS is responsible for directory reading when
you have a name but not yet a FID.
paramucho
wrote:
>On 2011-09-08 11.54, paramucho wrote:
>> On Thu, 08 Sep 2011 08:27:28 +0200, Johnny Billquist<b...@softjar.se>
>> wrote:
>>
>>> On 2011-09-08 08.16, paramucho wrote:
<snip>
>What is RUST though? I know I've seen the name, but I can't remember
>right now.
See: http://rust.wikispaces.com/About+Rust
<snip>
>> I successfully logged in (after I remembered how HELLO works) and I
>> managed to look around, but I couldn't see any test programs.
>
>DU:[IPLIB]TEST4.MAC
I got TEST4.MAC. Now I'm tweaking my RSX emulator code--it's been
inactive for a couple of decades and MAC is running out of space.
Ian
Johnny Billquist
> On Thu, 08 Sep 2011 14:32:32 +0200, Johnny Billquist<b...@softjar.se>
> wrote:
>
>> On 2011-09-08 11.54, paramucho wrote:
>> What is RUST though? I know I've seen the name, but I can't remember
>> right now.
>
> See: http://rust.wikispaces.com/About+Rust
>>> I successfully logged in (after I remembered how HELLO works) and I
>>> managed to look around, but I couldn't see any test programs.
>>
>> DU:[IPLIB]TEST4.MAC
>
> I got TEST4.MAC. Now I'm tweaking my RSX emulator code--it's been
> inactive for a couple of decades and MAC is running out of space.
But the program is short, and should be pretty obvious.
Johnny
paramucho
>On 2011-09-08 19.12, paramucho wrote:
>> On Thu, 08 Sep 2011 14:32:32 +0200, Johnny Billquist<b...@softjar.se>
>> wrote:
>>
>>> On 2011-09-08 11.54, paramucho wrote:
>>> What is RUST though? I know I've seen the name, but I can't remember
>>> right now.
>>
>> See: http://rust.wikispaces.com/About+Rust
>
>Nice. Interesting to be able to emulate RSX to that level on top of RT-11.
RT-11 It's a reasonably clean multi-user/multi-process system that
uses RT-11 as its native API. There's no DEC RT-11 cosde in it. RSX
was pretty easy to add in (modelled on the RSX AME on VMS). There's
also Unix AME half-finished somewhere.
>>>> I successfully logged in (after I remembered how HELLO works) and I
>>>> managed to look around, but I couldn't see any test programs.
>>>
>>> DU:[IPLIB]TEST4.MAC
>>
>> I got TEST4.MAC. Now I'm tweaking my RSX emulator code--it's been
>> inactive for a couple of decades and MAC is running out of space.
>
>Heh. Yeah, RMS stuff probably strains MACRO-11 somewhat.
>But the program is short, and should be pretty obvious.
ago. It didn't get a lot of testing then. I've now assembled
TEST4.MAC, but I got lots of .MACRO errors. I may have the wrong
RSXMAC.SML and/or RMSMAC.MLB. I'll look at that tomorrow.
Ian
Johnny Billquist
Johnny
paramucho
Ian
Johnny Billquist
have a tftp server. Sorry, I haven't written any FTP client or server yet...
Or you could convert the compiled file to text (I have a tool for that),
and then just use PIP like in my example before. As long as you have
some remote site that can accept raw data on a TCP socket. :-)
Johnny
paramucho
wrote:
It took me some time to organise all the RSX bits and pieces I had
around the place and to understand some RSX basics, but I finally
managed to get an RSX 4.4 system with RMS from an 4.2 system together
under my emulator. That meant I could compile using FLX to get stuff
in and out. Of course, once the tools were right the rest of it took
little time at all.
I reduced the test program down to basically $OPEN of a fixed FAB and
NAM block with a name of "ZZ:Z.Z" which allowed me to use logical
names at run time.
It was simple to find the address of the GLUN directive (using trace),
but it was, as I had suspected, tedious tracking RMS as it looked at
the various LUN flags (SEQ, SDI etc), so I implemented a "feelpoint"
in the emulator, a kind-of watchpoint which tracks any kind of
reference at all to a particular location (in fact I put the code in
the middle of the emulator's MMU VA translation routine). This let me
see every reference RMS made to LUN flags.
In the code below I've set a breakpoint just following RMS's GLUN
directive. Using the TKB map I located the PSECT (shown with address
and length) and the closest global label (shown with address). Using
this information it should be pretty easy to set a breakpoint in this
code, even if there are small variations.
=====================================================================
; The GLUN is emitted in psect R0OPFL in routine $OPNCM
Psect: R0OPFL 12114 700
Label: $OPNCM 12114
15502 glun lun=1 buf=1126
Break: PC=15502 OP=2
15502u 12623 pop (r3)+ | r6 store device name
SP 1126 2 126 N8 [V.] | r3
R3 42612 105 212 KEB [.E] | s
15504u 112613 225 213 W7C [..] | \
15504u 112613 movb (sp)+,(r3) | s store channel
15506u 13702 mov @#56,r2 | s Work area
15512u 15202 mov @-(r2),r2 | s RMS area?
15514u 42716 bic #300,(sp) | s zap upper flags
; For the rest of the session I set my breakpoint on the next opcode.
; The LUN characteristics are now on the top of the stack.
; Thus they can be altered at this point before being moved into
; internal RMS structures. RMS stores them twice, but it's the second
; location which I think is the main one.
15520u 111662 movb (sp),177746(r2) | s store in RMS area
2566 (fab area)
15524u 16202 mov 177670(r2),r2 | s
15530u 112662 movb (sp)+,6(r2) | s store it again
r2+6 = 41240 1010
15534u 32626 bit (sp)+,(sp)+ |41240f set the "feelpoint"
15536u 12662 pop 24(r2) |
15542u 111360 movb (r3),177776(r0) |
15546u 14360 mov -(r3),177774(r0) |
15552u 207 return |
41240f:
41240 1010
14324u 116260 movb 6(r2),3(r0) |
==============================================================
; In all the routines below 6(r4) holds the LUN class flags
; I used a "feelpoint" on location 41240 to catch these references
; The first reference is in PSECT R0OPFL in the $OPNCM routine.
; The first test is to see whether the LUN is record oriented...
Psect: R0OPFL 12114 700
Label: $OPNCM 12114
12140u 132764 bitb #1,6(r4) | ; is it record oriented?
12146u 1124 bne 12420 | ; no
12150u 32765 bit #10000,177706(r5) |
12156u 1402 beq 12164 |
12160u 5710 tst (r0) |
12162u 1016 bne 12220 |
12164u 4767 call 24772 |
12170u 103471 bcs 12354 |
12172u 4767 call 25224 |
12176u 103466 bcs 12354 |
12200u 4767 call 24622 |
12204u 103463 bcs 12354 |
12206u 4767 call 26444 |
12212u 4767 call 26224 |
12216u 103456 bcs 12354 |
12220u 132764 bitb #40,6(r4) |
12226u 1047 bne 12346 |
12230u 4767 call 21644 |
12234u 16520 mov 177764(r5),(r0)+ |
12240u 5046 clr -(sp) |
12242u 10446 psh r4 |
12244u 62716 add #32,(sp) |
12250u 12746 psh #12374 |
12254u 10610 mov sp,(r0) |
12256u 12701 mov #177540,r1 |
12262u 12702 mov #13000,r2 |
12266u 4767 call 24404 |
12272u 5226 inc (sp)+ |
12274u 113616 movb @(sp)+,(sp) |
12276u 103426 bcs 12354 |
12300u 162716 sub #60,(sp) |
12304u 62726 add #40,(sp)+ |
12310u 103016 bcc 12346 |
12312u 132764 bitb #40,7(r4) |
12320u 1012 bne 12346 |
12322u 12715 mov #177740,(r5) |
12326u 116401 movb 50(r4),r1 |
12332u 1410 beq 12354 |
12334u 12715 mov #177500,(r5) |
12340u 22701 cmp #40,r1 |
etc
==================================
; The next test is for sequential
12616u 16401 mov 6(r4),r1 | ; is it sequential
12622u 32701 bit #40,r1 | ; no
12626u 1454 beq 12760 |
12630u 32701 bit #20000,r1 |
12634u 1012 bne 12662 |
12636u 12715 mov #175160,(r5) |
12642u 22700 cmp #1377,r0 |
12646u 103642 bcs 12354 |
12650u 52714 bis #100000,(r4) |
12654u 152764 bisb #10,33(r4) |
12662u 10400 mov r4,r0 |
12664u 62700 add #46,r0 |
12670u 5010 clr (r0) |
12672u 12740 mov #177777,-(r0) |
12676u 11040 mov (r0),-(r0) |
12700u 32701 bit #16400,r1 |
12704u 1410 beq 12726 |
12706u 32765 bit #1000,177706(r5) |
12714u 1004 bne 12726 |
12716u 5020 clr (r0)+ |
12720u 5410 neg (r0) |
12722u 52714 bis #4000,(r4) |
12726u 5016 clr (sp) |
12730u 16400 mov 14(r4),r0 |
12734u 4767 call 21756 |
12740u 32716 bit #3,(sp) |
12744u 1002 bne 12752 |
12746u 167 jmp 21340 |
12752u 12716 mov #142,(sp) |
12756u 414 br 13010 |
==============================================================
Psect: R0RXDI 24404 2062
Label: $RXDID 24772
; In this routine it excludes record oriented, etc.
25014u 132764 bitb #61,6(r4) |
25022u 1066 bne 25200 |
25024u 162703 sub #12,r3 |
25030u 12713 mov #1,(r3) |
25034u 12743 mov #15172,-(r3) |
25040u 16002 mov 54(r0),r2 |
25044u 116001 movb 52(r0),r1 |
25050u 3425 ble 25124 |
25052u 5301 dec r1 |
25054u 10115 mov r1,(r5) |
25056u 60215 add r2,(r5) |
25060u 4767 call 25702 |
25064u 103025 bcc 25140 |
25066u 32323 bit (r3)+,(r3)+ |
25070u 5013 clr (r3) |
25072u 122712 cmpb #54,(r2) |
25076u 1012 bne 25124 |
25100u 10246 psh r2 |
25102u 4767 call 26052 |
25106u 12615 pop (r5) |
25110u 103405 bcs 25124 |
25112u 16002 mov 54(r0),r2 |
25116u 4767 call 26052 |
25122u 103003 bcc 25132 |
25124u 12715 mov #177060,(r5) |
25130u 474 br 25322 |
25132u 52760 bis #1,72(r0) |
25140u 4767 call 24622 |
25144u 103006 bcc 25162 |
25146u 22715 cmp #176440,(r5) |
25152u 1002 bne 25160 |
25154u 12715 mov #177020,(r5) |
25160u 460 br 25322 |
25162u 10003 mov r0,r3 |
25164u 62703 add #24,r3 |
25170u 12023 mov (r0)+,(r3)+ |
25172u 12023 mov (r0)+,(r3)+ |
25174u 11013 mov (r0),(r3) |
25176u 34040 bit -(r0),-(r0) |
==============================================================
Psect R0RXDI 24404 2062
Label $RXENT 24634
24726u 132764 bitb #40,6(r4) |
24734u 1407 beq 24754 |
24736u 32765 bit #1,177706(r5) |
24744u 1403 beq 24754 |
24746u 52760 bis #4000,10(r0) |
24754u 4767 call 24404 |
24760u 12600 pop r0 |
24762u 12760 mov #0,20(r0) |
24770u 207 return |
ETC
25536u 132764 bitb #40,6(r4) |
...
==========================================================
And of course there's a lot more of this. It's a tedious task walking
through it all, but the material will come in handy if an attempt is
made to patch RMS.
I note that RMS immediately clears flags 100 and 200. That might mean
that they're available, but probably means that RMS is using them
internally for other conditions.
By playing around with LUN flags on the top of the stack I was able to
watch whether RMS went on to use FNA or not. I'll have a bit more of a
look at that tomorrow.
Hope this all makes some kind of sense...
Ian
Johnny Billquist
I've been tracing through a lot of this myself as well...
We'll see what I end up with. I'd be happy to continue this in private
mail, since I suspect this is getting a bit too internal to be of much
general interest. :-)
Johnny