OS2200 questions.

[dkal...@gmail.com]

Question 1:
In BOOT1, the first thing in BSBLK is an LMJ to UPDBDT.
The first thing in UPDBDT is saving off B2's VA, and then loading it into A0 and fiddling with it, and indexing from it.

So I have to assume that B2 (and X2) are set to something useful prior to transferring control to BSBLK... what is that?



Question 2:
Is the entire EXEC now in Extended Mode? I presumed so, but apparently I was wrong.

I saw a few 74 04 00 instructions in DAPA $(1), which the hardware guide says is a Jump instruction, but only for Basic Mode. I also saw some 07 17 xx's with xx != 0, which is LBJ in BM, and not defined for EM...

It appears that DAPA at least, is still BM.
What about BOOT1?

[David Schroth]

On Thu, 28 Mar 2013 21:54:50 -0700 (PDT), dkal...@gmail.com wrote:

>Question 1:
>In BOOT1, the first thing in BSBLK is an LMJ to UPDBDT.
>The first thing in UPDBDT is saving off B2's VA, and then loading it into A0 and fiddling with it, and indexing from it.
>
>So I have to assume that B2 (and X2) are set to something useful prior to transferring control to BSBLK... what is that?
>

Off the top of my head, I don't know. I know that someone just had to
fix UPDBDT, because someone rather foolishly used X1 in code running
in the Exec register set.

At a guess, I'd say B2 probably contains ICLP's Level 0 BDT

>
>
>Question 2:
>Is the entire EXEC now in Extended Mode? I presumed so, but apparently I was wrong.
>

You were wrong. Well over 90% of executed Exec instructions are EM,
but there's still significant chunks of infrequently executed BM Exec
code.

>I saw a few 74 04 00 instructions in DAPA $(1), which the hardware guide says is a Jump instruction, but only for Basic Mode. I also saw some 07 17 xx's with xx != 0, which is LBJ in BM, and not defined for EM...

So you're running an older, most likely unsupported Exec. I converted
DAPA to extended mode several Exec levels ago.

>
>It appears that DAPA at least, is still BM.
>What about BOOT1?

BOOT1 has been EM since Lewis wrote it several decades ago. It
doesn't look much like the rest of the Exec; Lewis made it look like
Forth, much to the chagrin/consternation of anyone needing to modify
or support it.

Regards,

David W. Schroth

[Kurt Duncan]

> At a guess, I'd say B2 probably contains ICLP's Level 0 BDT

I'll work from that premise, and see how it goes.

> So you're running an older, most likely unsupported Exec.  I converted
> DAPA to extended mode several Exec levels ago.

48R6, I believe. Anyway, that's what's in E8ID.

> BOOT1 has been EM since Lewis wrote it several decades ago.  It
> doesn't look much like the rest of the Exec;  Lewis made it look like
> Forth, much to the chagrin/consternation of anyone needing to modify
> or support it.

LOL. I have actually played with Forth, so it should be clear as
glass to me.
This is my first attempt at a disassembler, so I'm only half-trusting
what I'm working from, anyway.
e.g., I pooched my f=05 lookup table entries, so most of the SZ, SNZ,
etc, didn't get disassembled, so they show up in FJAXHIU mode in the
middle of otherwise nicely-formatted instruction output.

How many people are actively working on Exec these days? Just you
now? :-)

Thanks...
k.

[David Schroth]

On Sat, 30 Mar 2013 21:25:32 -0700 (PDT), Kurt Duncan
<dkal...@gmail.com> wrote:

>> At a guess, I'd say B2 probably contains ICLP's Level 0 BDT
>
>I'll work from that premise, and see how it goes.
>
>> So you're running an older, most likely unsupported Exec.  I converted
>> DAPA to extended mode several Exec levels ago.
>
>48R6, I believe. Anyway, that's what's in E8ID.

As I guessed, an older, unsupported level.

>
>> BOOT1 has been EM since Lewis wrote it several decades ago.  It
>> doesn't look much like the rest of the Exec;  Lewis made it look like
>> Forth, much to the chagrin/consternation of anyone needing to modify
>> or support it.
>
>LOL. I have actually played with Forth, so it should be clear as
>glass to me.
>This is my first attempt at a disassembler, so I'm only half-trusting
>what I'm working from, anyway.
>e.g., I pooched my f=05 lookup table entries, so most of the SZ, SNZ,
>etc, didn't get disassembled, so they show up in FJAXHIU mode in the
>middle of otherwise nicely-formatted instruction output.
>
>How many people are actively working on Exec these days? Just you
>now? :-)
>

More than just me, although most of the bodies are in I/O (rather than
MSM or PCN).

I took a look at the code. It turns out that the contents of B2 are
undefined on entry, because the ONVERSION3E folk didn't bother to
update the header documentation. As best I can tell, ICLP is based on
B2 for ONVERSION3E machines. It's not clear why this is the case.
>Thanks...
>k.

Regards,

David W. Schroth

[dkal...@gmail.com]

On Thursday, April 4, 2013 8:49:09 AM UTC-6, David Schroth wrote:
> On Sat, 30 Mar 2013 21:25:32 -0700 (PDT), Kurt Duncan
>

> >How many people are actively working on Exec these days? Just you
> >now? :-)
>
> More than just me, although most of the bodies are in I/O (rather than
> MSM or PCN).
>

How's the weather in Roseville? (assuming, of course, you are based there)

> I took a look at the code. It turns out that the contents of B2 are
> undefined on entry, because the ONVERSION3E folk didn't bother to
> update the header documentation. As best I can tell, ICLP is based on
> B2 for ONVERSION3E machines. It's not clear why this is the case.

I wondered why EXEC BDI's started so high (0157, IIRC). Turns out, some 64 or so, are reserved for banks which are/might be created by the SCF/ICLP/whatever, to pass to the OS. UPDBDT* is, of course, fixing up these BD's in what becomes the L0 BDT. ICLP tells BOOT1 how many of these have actual data, and UPDBTD* fixes those, and voids-out the rest.

Some of those lower BDT's are adjusted to describe subsets of BOOT1 for stacks, data, etc. But at least one of them (000056) points to something (presumably *not* in B2's bank) which provides data to BOOT*.

-----------------

I noticed something odd around BOOT1 $(0)+022... We grab some info into EA1 (from B2's bank, of course), which seems to be the number of real banks from ICLP/whatever in H1, and something else in H2. We OR that into EA2 with the following strangeness:
$(0)+00024 | OR EA1,X0 . 400020000000
Given that H2 of EA2 eventually becomes an upper limit for BD's, why would an OR of *anything* be appropriate, and why does the OR'd value come from X0?
Anyway... that's not the point. Keep in mind that EA2:H1 still has number of live banks. Now go look in the loop where BD's are updated... EA2 gets SSL'd by 6, to store the 64-word resolution upper limit into the successive BD's (and LSSL'd back again). BUT... unrelated number of banks in H1 comes along for the ride. It probably doesn't hurt anything, but it doesn't seem right. And, yeah, unsupported, so mox nix, but if the code is still in *supported* versions, it might need a look-over.

---------------

All of that begs the question, what *else* besides Partition Databank is being handed to the OS when it boots up? I had thought that B2 had the partition databank, since so much stuff is pulled from it (e.g., H1 of 0241 indicates whether we boot from tape or... something else).

*BUT* CHKPDB* argues otherwise - assuming it checks the partition databank for validity, then PDB is based on B8, and comes from bank 000056 (the 1st bank dealt with by UPDBDT*). So, B2->ICLP's bank (as you said) which has lots of boot info which we need, and B8->000056, which is the partition databank.

Ongoing...

OH, and I have a new guess WRT IPC sf=025 and 030. But I'm reserving my guess until I look at the code more closely. It does appear that they need the real address of some command packet in EA1/EA2...

[David Schroth]

On Sat, 6 Apr 2013 19:14:28 -0700 (PDT), dkal...@gmail.com wrote:

>On Thursday, April 4, 2013 8:49:09 AM UTC-6, David Schroth wrote:
>> On Sat, 30 Mar 2013 21:25:32 -0700 (PDT), Kurt Duncan
>>
>> >How many people are actively working on Exec these days? Just you
>> >now? :-)
>>
>> More than just me, although most of the bodies are in I/O (rather than
>> MSM or PCN).
>>
>
>How's the weather in Roseville? (assuming, of course, you are based there)
>

The weather in Minnesota in April is pretty much like the weather is
in April in Minnesota any year - if you don't like the current
weather, wait 30 minutes, and see if the next batch is more to your
liking.

>
>> I took a look at the code. It turns out that the contents of B2 are
>> undefined on entry, because the ONVERSION3E folk didn't bother to
>> update the header documentation. As best I can tell, ICLP is based on
>> B2 for ONVERSION3E machines. It's not clear why this is the case.
>
>I wondered why EXEC BDI's started so high (0157, IIRC). Turns out, some 64 or so, are reserved for banks which are/might be created by the SCF/ICLP/whatever, to pass to the OS. UPDBDT* is, of course, fixing up these BD's in what becomes the L0 BDT. ICLP tells BOOT1 how many of these have actual data, and UPDBTD* fixes those, and voids-out the rest.
>

The Exec's BDT starts at 0160, and it starts that high because I
defined it to start that high.

There is a good reason for why I defined it to start at 0160, but I no
longer remember what it is.

>Some of those lower BDT's are adjusted to describe subsets of BOOT1 for stacks, data, etc. But at least one of them (000056) points to something (presumably *not* in B2's bank) which provides data to BOOT*.
>

That's almost certainly the Partition Data Bank, which can be a large
bank (but has never been one in my experience).

>-----------------
>
>I noticed something odd around BOOT1 $(0)+022... We grab some info into EA1 (from B2's bank, of course), which seems to be the number of real banks from ICLP/whatever in H1, and something else in H2. We OR that into EA2 with the following strangeness:
> $(0)+00024 | OR EA1,X0 . 400020000000
>Given that H2 of EA2 eventually becomes an upper limit for BD's, why would an OR of *anything* be appropriate, and why does the OR'd value come from X0?
>Anyway... that's not the point. Keep in mind that EA2:H1 still has number of live banks. Now go look in the loop where BD's are updated... EA2 gets SSL'd by 6, to store the 64-word resolution upper limit into the successive BD's (and LSSL'd back again). BUT... unrelated number of banks in H1 comes along for the ride. It probably doesn't hurt anything, but it doesn't seem right. And, yeah, unsupported, so mox nix, but if the code is still in *supported* versions, it might need a look-over.
>

I suspect the code in question was stolen from somewhere else, and
it's almost certainly good. And I've given up working on the
ONVERSION3E machines, so it's unlikely I'll take a look at the code.

>---------------
>
>All of that begs the question, what *else* besides Partition Databank is being handed to the OS when it boots up? I had thought that B2 had the partition databank, since so much stuff is pulled from it (e.g., H1 of 0241 indicates whether we boot from tape or... something else).
>

Well, everything needed to access the stuff needed by bootstrap is
described in ICLP fixed addresses. I can figure out why ICLP ends up
based on B2 - it's an artifact of the ONVERSION3E architecture.

>*BUT* CHKPDB* argues otherwise - assuming it checks the partition databank for validity, then PDB is based on B8, and comes from bank 000056 (the 1st bank dealt with by UPDBDT*). So, B2->ICLP's bank (as you said) which has lots of boot info which we need, and B8->000056, which is the partition databank.
>
>Ongoing...
>
>OH, and I have a new guess WRT IPC sf=025 and 030. But I'm reserving my guess until I look at the code more closely. It does appear that they need the real address of some command packet in EA1/EA2...

There is no such thing as a real address on that (ONVERSION3E)
architecture. It might be better if there were, but that's a
different discussion.

Regards,

David W. Schroth

[Kurt Duncan]

On Apr 7, 1:31 pm, David Schroth <davidschr...@harrietmanor.com>
wrote:

>
> The weather in Minnesota in April is pretty much like the weather is
> in April in Minnesota any year - if you don't like the current
> weather, wait 30 minutes, and see if the next batch is more to your
> liking.

Sounds like Kansas, where I used to live.

> I suspect the code in question was stolen from somewhere else, and
> it's almost certainly good.  And I've given up working on the
> ONVERSION3E machines, so it's unlikely I'll take a look at the code.

Fair enough.

> There is no such thing as a real address on that (ONVERSION3E)
> architecture.  It might be better if there were, but that's a
> different discussion.

Indeed.
....
For me, this is a (possibly sad and pathetic) hobby. For you, it's
work. I appreciate your commentary, and thank you for your time.
k.

[Marc Wilson]

In comp.sys.unisys, (David Schroth) wrote in
<1rh3m8to5ffcke122...@4ax.com>::

>
>The weather in Minnesota in April is pretty much like the weather is
>in April in Minnesota any year - if you don't like the current
>weather, wait 30 minutes, and see if the next batch is more to your
>liking.

The joke I've heard about Minnesota is that there are only two seasons:
winter, and road-repair.
--
Marc Wilson

Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 844 779 0968 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE

https://plus.google.com/100816173414569062406
_________________________________________________________________
Try MailTraq at https://my.mailtraq.com/register.asp?code=cleopatra

[Scott Lurndal]

Marc Wilson <ma...@cleopatra.co.uk> writes:
>In comp.sys.unisys, (David Schroth) wrote in
><1rh3m8to5ffcke122...@4ax.com>::
>
>>
>>The weather in Minnesota in April is pretty much like the weather is
>>in April in Minnesota any year - if you don't like the current
>>weather, wait 30 minutes, and see if the next batch is more to your
>>liking.
>
>The joke I've heard about Minnesota is that there are only two seasons:
>winter, and road-repair.
>

Mosquito season and the rest of the year.

scott