Proc32's -l @w option parameter format?

Hi folks,

What’s the physical address format for the -l @w option to Proc32? Can
anyone give a working example?

Thanks :slight_smile:

  • Nick

Nikolai Gorbunov <n.gorbunov@swd.ru> wrote:

Hi folks,

What’s the physical address format for the -l @w option to Proc32? Can
anyone give a working example?

The physical address format is decimal. I don’t have a working
example – in-house we generally just use the simple -l node
format.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

What’s the physical address format for the -l @w option to Proc32? Can
anyone give a working example?

The physical address format is decimal. I don’t have a working
example – in-house we generally just use the simple -l node
format.

Sorry, did you mean decimal or HEXAdecimal? The docs state the latter, ‘the
truth is out there’.

I tested the option launching Proc32 as ‘Proc32 -l@w400’ (because the first
word of BIOS data area is easy to know), the resultimg NID was [0:400]+1,
i.e. 0x3F8 + 1 = 0x3F9 = 1017 - as expected. So I just wanted to ask if the
option paramener should be just a plain linear address anyway, or there is
something more quirky deep inside.

P.S. Still, why is the resulting NID always set to the specified NID + 1?
The ‘Proc32 and node number’ thread (March 2001) did not clarify this to me.

Thanks,

  • Nick

Nikolai Gorbunov <n.gorbunov@swd.ru> wrote:

What’s the physical address format for the -l @w option to Proc32? Can
anyone give a working example?

The physical address format is decimal. I don’t have a working
example – in-house we generally just use the simple -l node
format.

Sorry, did you mean decimal or HEXAdecimal? The docs state the latter, ‘the
truth is out there’.

I meant decimal – my docs (both online and printed) state hex for every
other option BUT the @w option. I’m not sure which it uses – go with
whichever works.

I tested the option launching Proc32 as ‘Proc32 -l@w400’ (because the first
word of BIOS data area is easy to know), the resultimg NID was [0:400]+1,
i.e. 0x3F8 + 1 = 0x3F9 = 1017 - as expected. So I just wanted to ask if the
option paramener should be just a plain linear address anyway, or there is
something more quirky deep inside.

I think it is supposed to be a plain linear address.

P.S. Still, why is the resulting NID always set to the specified NID + 1?
The ‘Proc32 and node number’ thread (March 2001) did not clarify this to me.

Hm… I know that a nid of 0 is invalid. So this may originally have been
to make sure you never had a nid of 0, but I have vague memories of this
being reported as a bug. (It might be exactly the thread you are talking
about from March 2001.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Nikolai Gorbunov <> n.gorbunov@swd.ru> > wrote:
What’s the physical address format for the -l @w option to Proc32? Can
anyone give a working example?
The physical address format is decimal. I don’t have a working
example – in-house we generally just use the simple -l node
format.
Sorry, did you mean decimal or HEXAdecimal? The docs state the latter, ‘the
truth is out there’.
I meant decimal – my docs (both online and printed) state hex for every
other option BUT the @w option. I’m not sure which it uses – go with
whichever works.

The src itself shows it expects a HEX arg (uses “strtol(…, 16)”). A
plain “-l” itself however expects DEC.

P.S. Still, why is the resulting NID always set to the specified NID + 1?
The ‘Proc32 and node number’ thread (March 2001) did not clarify this to me.
Hm… I know that a nid of 0 is invalid. So this may originally have been
to make sure you never had a nid of 0, but I have vague memories of this
being reported as a bug. (It might be exactly the thread you are talking

It is not that it adds 1, but that the number sourced from memory/io port
is added to the bound-in node number (which defaults to 1). This allows
you to partition your network by using multiple ‘-l’ options. For
example, have some machines with “-l100 -l@w400” in their boot file and
some with “-l200 -l@w400” and the same hardware can now generate
different ranges of network address, or you can move the self-configuring
machines off into a subrange. This also shows that if you consider the
so-called “NID + 1” an inconvenience, then “-l0 -l@w400” will help … :wink:

John Garvey <jgarvey@qnx.com> wrote:
: David Gibbs <dagibbs@qnx.com> wrote:
:> I meant decimal – my docs (both online and printed) state hex for every
:> other option BUT the @w option. I’m not sure which it uses – go with
:> whichever works.

: The src itself shows it expects a HEX arg (uses “strtol(…, 16)”). A
: plain “-l” itself however expects DEC.

I’ll fix the docs.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

Hi Steve

Are you still making any DOCS changes to QNX4?

If so, what may have been changed in the last two years and were can I get
copy. I haven’t seen anything new on QUICS:/updates for a while.

“Steve Reid” <stever@qnx.com> wrote in message
news:al7krj$q4v$1@nntp.qnx.com

John Garvey <> jgarvey@qnx.com> > wrote:
: David Gibbs <> dagibbs@qnx.com> > wrote:
:> I meant decimal – my docs (both online and printed) state hex for
every
:> other option BUT the @w option. I’m not sure which it uses – go with
:> whichever works.

: The src itself shows it expects a HEX arg (uses “strtol(…, 16)”). A
: plain “-l” itself however expects DEC.

I’ll fix the docs.


Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:
: Hi Steve

: Are you still making any DOCS changes to QNX4?

I don’t think we’ve made any major changes, but we do make corrections as
they come up.

: If so, what may have been changed in the last two years and were can I get
: copy. I haven’t seen anything new on QUICS:/updates for a while.

I’m afraid I don’t know of any specific plans to release new docs, but I
live in hope. :slight_smile:


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems