Anyone worked with the Hornby Zero One  system?

Charlie

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

<<snip>>
>
> It would be great if somebody wanted to write some better
> documentation.  A manual, even a very basic one, would be _really_
> great.

Hmmm... Mebbe I'm being stupid... but I'll take a shot at it.

Given the frequency of change of the program, I suspect an HTML format would be
best (and simplest to allow inclusion of screen shots), with one "page" per tab.
I'll play with it and see what I can come up with.

A member of the DCCUK NG has provided me with a few links to sites
containing decoder information. The sites are based written in
German but I'm not capable of translating to English. If someone
here is capable of doing so and is willing to assist, please contact
me off list.

Thanks
Bob Blackwell

You can get a good idea of what is said by using the following
translator...

http://www.freetranslation.com/

Tom....




--- In jmriusers@y..., "original_black_bart" <rc_blackwell@...:
> A member of the DCCUK NG has provided me with a few links to sites
> containing decoder information. The sites are based written in
> German but I'm not capable of translating to English. If someone
> here is capable of doing so and is willing to assist, please
contact
> me off list.
>
> Thanks
> Bob Blackwell

I've uploaded a new Windows installer, plus archive files for MacOS X
and Macintosh OS 8 & 9.  The downloads are:

Mac OS 8, 9:   http://prdownloads.sourceforge.net/jmri/MacClassic.1.0.6.hqx

MacOS X:  http://prdownloads.sourceforge.net/jmri/MacOSX.1.0.6.hqx

Windows:  http://prdownloads.sourceforge.net/jmri/JMRI.1.0.6.exe

You only need to download _one_ of these, depending on your computer
type! In all cases, you need to have the 1.0 version installed and
working first.

Windows users, just download and execute the file to install.

Users of the new and old Macintosh just download the appropriate file
and expand the contents onto their disk.  This will give you a folder
from which you can run the program.

If anybody wants a version for Linux, OS/2 or another system, just
let me know your preferred form.

Note that this is a test version; you should make a copy of your
existing version first.

Changes include:

1) New PM4 programming tool in JmriDemo and LocoTools apps.

2) Can now rotate turnout, sensor, signal icons on control panels

3) Fix inconsistent turnout icons on the panel editor.

Windows only:

4) DOS windows should now be hidden when program is running, close
when programs exit

5) Java2D option set to avoid problems drawing certain screens

Macintosh only:

4) Remove small fonts from speed-table edit pane to avoid a problem
with older Java version on Macintosh.


Please let me know of any problems.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

At 11:59 PM +0000 8/30/02, barr_ceo wrote:
>DL went well, and I moved the files to the JMRI folder as directed.
>The splash screen and decoder selection worked OK, but when I tried to
>open a full (complex) decoder window the JAVA pane opened and I got the
>following error messages:
>
>--------
>Exception occurred during event dispatching:
>java.lang.NoSuchMethodError: java.awt.Font: method deriveFont(F)Ljava/
>awt/Font; not found


I think I've got this fixed in the 1.0.6 version.  You can try
downloading that from:

    http://prdownloads.sourceforge.net/jmri/MacClassic.1.0.6.hqx

This is a complete new folder, rather than parts you need to move to
the existing folder.  That makes it a little larger, but is so much
simpler for people that it seems the right way to distribute this.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

I use  http://babelfish.altavista.com/ for the same thing.
David

tomgrayll wrote:

> You can get a good idea of what is said by using the following
> translator...
>
> http://www.freetranslation.com/
>
> Tom....
>
> --- In jmriusers@y..., "original_black_bart" <rc_blackwell@...:
> > A member of the DCCUK NG has provided me with a few links to sites
> > containing decoder information. The sites are based written in
> > German but I'm not capable of translating to English. If someone
> > here is capable of doing so and is willing to assist, please
> contact
> > me off list.
> >
> > Thanks
> > Bob Blackwell
>
>
> To unsubscribe from this group, send an email to:
> jmriusers-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
David Harris
   OmniPort Home Page:  http://www3.telus.net/OmniPort1/
     Discussion egroup: http://groups.yahoo.com/group/OmniPort
     Swiki:  http://omniport.swiki.net/1

Thanks Gents. Both work great.

Bob

--- In jmriusers@y..., David Harris <dpharris@t...> wrote:
> I use  http://babelfish.altavista.com/ for the same thing.
> David
>
> tomgrayll wrote:
>
> > You can get a good idea of what is said by using the following
> > translator...
> >
> > http://www.freetranslation.com/
> >
> > Tom....
> >
> > --- In jmriusers@y..., "original_black_bart" <rc_blackwell@h...:
> > > A member of the DCCUK NG has provided me with a few links to
sites
> > > containing decoder information. The sites are based written in
> > > German but I'm not capable of translating to English. If
someone
> > > here is capable of doing so and is willing to assist, please
> > contact
> > > me off list.
> > >
> > > Thanks
> > > Bob Blackwell
> >
> >
> > To unsubscribe from this group, send an email to:
> > jmriusers-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
> --
> David Harris
>   OmniPort Home Page:  http://www3.telus.net/OmniPort1/
>     Discussion egroup: http://groups.yahoo.com/group/OmniPort
>     Swiki:  http://omniport.swiki.net/1

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

> I think I've got this fixed in the 1.0.6 version.  You can try
> downloading that from:
>
>    http://prdownloads.sourceforge.net/jmri/MacClassic.1.0.6.hqx
>
> This is a complete new folder, rather than parts you need to move to
> the existing folder.  That makes it a little larger, but is so much
> simpler for people that it seems the right way to distribute this.
>
> Bob

I'll keep this simple...

Y   Y EEEEE  SSSS     !
  Y Y  E         S            !
   Y    EEE       SSS      !
   Y    E                 S
   Y    EEEEE SSSS     @

<<big silly grin>>

I'll have to take a look at the code for the graphing functions. The PR1
software has a feature where you can input a few elements of the speed table and
it will "connect the dots". It would be nice to be able to do that to non-zero
random midpoints, not just the endpoints. It would save a lot of mousework. Ah,
well... it's almost 1:30 AM here... time enough for that tomorrow!

At 5:23 AM +0000 9/3/02, barr_ceo wrote:
>
>
>I'll have to take a look at the code for the graphing functions. The
>PR1 software has a feature where you can input a few elements of the
>speed table and it will "connect the dots". It would be nice to be
>able to do that to non-zero random midpoints, not just the
>endpoints. It would save a lot of mousework. Ah, well... it's almost
>1:30 AM here... time enough for that tomorrow!
>

I think the hard part is figuring out a nice interface for this.
I''m not familar with the PR1 software, perhaps they've solved that?

A while back, somebody (I think it might have been Dave Falkenberg,
but am not sure) suggested adding a check box at the bottom of each
slider in the speed table.  If an unchecked slider was moved, it
would do the same thing they do now.  But if you moved a checked
slider, it would draw a straight line to the nearest checked slider
on either side.

In other words, you could checkmark a couple of sliders which would
server as the "midpoints", and then slide them around with the
program filling in straight-line interpolations in between.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the jmriusers
group.

   File        : /DecoderPro_Manual/Index.html
   Uploaded by : barr_ceo <filker@...>
   Description : Online HTML user manual for DecoderPro 1.0.6

You can access this file at the URL

http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Index.html

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

barr_ceo <filker@...>

--- In jmriusers@y..., jmriusers@y... wrote:
>
> Hello,
>
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the jmriusers
> group.
>
>   File        : /DecoderPro_Manual/Index.html
>   Uploaded by : barr_ceo <filker@m...>
>   Description : Online HTML user manual for DecoderPro 1.0.6
>
> You can access this file at the URL
>
> http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Index.html
>
<<snip>>

OK, I _think_ I've got all the big kinks worked out... links going to
pages (where they should)instead of graphics, that sort of thing. I
_am_ interested in comments, whatever... especially typos I need to
fix.

The main page will always keep the same name (index.html) so links to
it should be stable as long as Yahoo is... <<grin>>

Just printed out Joe's manual and will start to digest it now.  I have
to say it's an impressive piece of work and it's just what we needed.  Thank
you Joe.

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

In review of this amazing user manual, I offer the following for
consideration;



-          Under the heading "How to select the right decoder
programmer"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Basic_P
rogramming.html#Setting%20Up); not all Command Systems provide read-back
capability. In cases such as these, the Indent Button will not be
available and the manual method of decoder selection must be utilized.



-          Under the heading "Using the Basic Programmer"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Basic_P
rogramming.html#Setting%20Up); as noted above, not all Command Systems
provide read-back capability. In cases such as these, the Read-Sheet and
Read-All Buttons will not be available for use.



-          In the first paragraph following the graphic displayed under
the heading "DecoderPro Comprehensive Programmer Motor Pane Control"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Comp_Mo
tor.html); the words acceleration and deceleration, which appear in
bold, are incorrectly spelt. There is only one "L" in each, not two as
typed. The same error occurs again in the third paragraph of the same
page.



-          First sentence in the first paragraph following the graphic
displayed under the heading "DecoderPro Comprehensive Programmer
Consisting Functions Pane"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Comp_Co
nsist.html); what is "EPS?"



-          Third sentence in the first paragraph following the graphic
displayed under the heading "DecoderPro Comprehensive Programmer
Consisting Functions Pane"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Comp_Co
nsist.html); the word Think is spelt wrong, it's missing the letter "i."



-          First paragraph following the heading "DecoderPro
Comprehensive Programmer Sound FX Pane"
(http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Comp_So
undFX.html); the current sentence reads "These sounds can be
coordinates..." Shouldn't it read "These sounds can be coordinated..."?
Note the spelling of the word coordinate.



Bob



--- In jmriusers@y..., jmriusers@y... wrote:

>

> Hello,

>

> This email message is a notification to let you know that

> a file has been uploaded to the Files area of the jmriusers

> group.

>

>   File        : /DecoderPro_Manual/Index.html

>   Uploaded by : barr_ceo <filker@m...>

>   Description : Online HTML user manual for DecoderPro 1.0.6

>

> You can access this file at the URL

>

>
http://groups.yahoo.com/group/jmriusers/files/DecoderPro_Manual/Index.ht
ml

>

> To learn more about file sharing for your group, please visit

>

> http://help.yahoo.com/help/us/groups/files

>

> Regards,

>

> barr_ceo <filker@m...>



[Non-text portions of this message have been removed]

--- In jmriusers@y..., "Bob Blackwell" <rc_blackwell@h...> wrote:
> In review of this amazing user manual, I offer the following for
> consideration;
>

<<bunch of good catches snipped...>>

OK, I got those corrected, and they'll appear in the next update.

I've been playing around with the software some more in conjunction with writing
up this manual, and the programming modes have thrown me. Bit mode and byte mode
I can at least guess at, but "address mode" doesn't appear to be what I thought
it would be - another name for ops mode.

Just what are the specific differences of these modes, and how are they best
applied? I can't put it in the manual iffn' I don't know... <<grin>>

At 2:30 PM +0000 9/5/02, barr_ceo wrote:
>
>I've been playing around with the software some more in conjunction
>with writing up this manual, and the programming modes have thrown
>me. Bit mode and byte mode I can at least guess at, but "address
>mode" doesn't appear to be what I thought it would be - another name
>for ops mode.
>
>Just what are the specific differences of these modes, and how are
>they best applied? I can't put it in the manual iffn' I don't
>know... <<grin>>


Address-mode is the original form.  I've never encountered a decoder
that does only address mode, nor a DCC system that only does address
mode.  But I put it in there because the NMRA spec says you gotta
have it. The NMRA specs are a wonder of options for things like this,
but they aren't really a good description of what _really_ goes on...

Register mode is an extension of address mode. You literally cannot
have register mode without address mode, as a write to the short
address in register mode is an identical sequence to an address mode
write.  But register mode only allows you to change a few things, not
all the various CVs.  There are some older register-mode-required
decoders still being sold, mostly from MRC and Wangrow.  And a _lot_
of people have them!

When trying to identify a decoder, register mode is the right way to
start, as most decoders can do it.  But note that register mode can't
read a long address (it can read the long/short selection bit, and
the short address), so if the program tries to identify a roster
entry and finds the loco in long-address mode, it has to pick another
programming mode.

The two most common/relevant modes are "paged" and "direct" for
current decoders.

Paged mode is an extension of register mode.  By setting a "page"
value, you can change the location that a register read/write acts on.

Direct mode has the advantage that you can test whether a decoder of
unknown type can do direct mode. Unfortunately, there are two
submodes in "direct" mode. Not all older decoders implement both, and
few (no?) DCC systems allow you to select which to use! The test
doesn't help you sort all this out.

To help, I allowed specifying whether the decoder (in the XML file)
and system (in the adapter classes) can do either, both or none of
the two modes. I called them "bit" and "byte"; they don't have
officialy names.

For example, some early Digitrax decoders do direct byte mode but not
direct bit mode.  This will matter if a system (e.g. some Lenz
hardware) only does direct bit mode.  For that combination, the right
choice is to use neither direct mode, but rather paged or register.

The program will gray-out modes that the attached DCC system can't
use.  But it _won't_ gray out modes that the current decoder can't
use.  It won't select those automatically, but it does allow you to
select them manually.  This may be a mistake, but my logic was "We
don't have files for every decoder ever made, and not all files are
perfect.  People might have a decoder that's a 'XXX except it also
allows this other mode', etc, so let's let them override the
program's choices".    If the concensus is that this is just too
error prone, we can change it.

There are various times when the program has to pick a mode:  When
you open a new selection/ID window, when you start programming of a
decoder with multiple modes for the first time, etc.  But it will
generally remember the mode used last, and try to use that again.

About the only time a user needs to be aware of the mode selection in
when having trouble with the ID buttons. In that case, they might
want to try another mode to see if communication can be established
better.

(Sorry for the stream-of-consciousness nature of this, wanted to get
it out quickly.  I'm sure others have a better understanding of the
details of how the modes work, why you'd use one, etc.)

Bob

--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Joe,
     Do you think Bob's discussion on decoder modes would be good to add to
the manual or just confusing?  If added it probably would go with "How to
select the right decoder programmer"  Your thoughts?

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

In practice (at our club), we typically use Paged Mode programming most
of the time.  We only use Register mode for really old decoders (MRC,
really old Lenz decoders).

-Dave Falkenburg
   Silicon Valley Lines

On Thursday, September 5, 2002, at 10:13 AM, Jon Miller wrote:

> Joe,
>     Do you think Bob's discussion on decoder modes would be good to
> add to
> the manual or just confusing?  If added it probably would go with "How
> to
> select the right decoder programmer"  Your thoughts?

Really a nice work!  I have just printed it and am sure it will be helpful
in mastering Decoder Pro.

I noticed in printing that:

The link to using Decoder Pro also includes the Using the Basic Programmer
section. I almost printed this section twice.

The last screen shot, Setup and Roster Panes, is too wide for the
document.  The right portion is clipped.

Now to get to what was asked about typo's etc.

BTW is filker@... the Joe Ellis recently of Orlando N'Trak fame?

Cheers


jerry snyder
Orlando, FL

>we typically use Paged Mode programming most of the time<
     Very true and I do also.  Except for one item I always make a mistake on
and that's the AD4 which is direct only.  Also I believe the RP's went to
suggesting all future decoders be direct (or something like that)!

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

At 10:13 AM -0700 9/5/02, Jon Miller wrote:
>     Do you think Bob's discussion on decoder modes would be good to add to
>the manual or just confusing?  If added it probably would go with "How to
>select the right decoder programmer"  Your thoughts?

A lot of what I do is just confusing...

Seriously, perhaps this could appear at several levels.  In the main
flow of the text you have something like "used paged unless its not
working right, in which case try register or direct", perhaps with a
sentence or two about the types of problems you'll encounter if
you've got an incompatibilty.  There could also be a link to more
info, that goes into a little more depth for those who really want to
learn more.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob Jacobsen wrote:

>The program will gray-out modes that the attached DCC system can't
>use.  But it _won't_ gray out modes that the current decoder can't
>use.  It won't select those automatically, but it does allow you to
>select them manually.  This may be a mistake, but my logic was "We
>don't have files for every decoder ever made, and not all files are
>perfect.  People might have a decoder that's a 'XXX except it also
>allows this other mode', etc, so let's let them override the
>program's choices".    If the concensus is that this is just too
>error prone, we can change it.

The original plan was to have the options grayed out when the decoder was
identified and such the identification allowed sufficient revision
information to know what the decoder supported.   But alas as many of you
know, the revision info does not always work given the inconsistency of
the how the revision codes are use and what they indicate.

However,  I would at least try to go with family definitions to limit the
options to a common subset that you know will work.  That way the system
always takes advantage of the best mode for that family.

Accidentally clicking on a programming mode button could lead to problems
as well as  showing to much information is potentially confusing.  I
would suggest that the program only show the current mode in real time.
However, clicking on the MODE display window would take you to a dialog
box  that shows you all the options and Defaults.  A note would tell
people what this is about and suggest leaving it alone unless they know
what they are doing.  Naturally there would be a cancel button to clear
the window without changing anything.



Best Regards,

Mark Gurries
Linear Technology
Power Supply & Battery charger Applications Engineer/Manager
---------------------------------------------------------
Model Railroad Club and NMRA DCC presentations are at:
http://www.siliconvalleylines.com/index.html
--------------------------------------------------------
Audio Enthusiast (Love SAE equipment)
http://members.ebay.com/aboutme/gurriesm/
http://www.wardsweb.org/audio/index_audio.html
----------------------------------------------------------

At 10:56 AM -0700 9/5/02, Jon Miller wrote:
>  >we typically use Paged Mode programming most of the time<
>     Very true and I do also.  Except for one item I always make a mistake on
>and that's the AD4 which is direct only.  Also I believe the RP's went to
>suggesting all future decoders be direct (or something like that)!

The AD4 is a good example of how it currently works.

When I opened an ID panel just now, it picked paged mode.  That would
have had trouble identifying an AD4 (though I don't have one to try
it with).  If I manually select AD4, though, and open the
programming, it will open in direct byte mode, and should work.

There are two steps there, which makes it confusing.  Good thing
we've got a manual to explain all this....

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

--- In jmriusers@y..., jerry snyder <jerrys@c...> wrote:
> Really a nice work!  I have just printed it and am sure it will be helpful
> in mastering Decoder Pro.

Umm... I didn't really think anyone would want to actually print this whole
thing out - rather, just use it online. When we get the initial kinks worked out
I'll try to do an archive file that has the whole thing in it so it can be
downloaded and accessed off your own computer instead of over the net. That will
speed things up considerably!

>
> I noticed in printing that:
>
> The link to using Decoder Pro also includes the Using the Basic Programmer
> section. I almost printed this section twice.

Probably because they're on the same "page"... I used "Targets" to go to the
appropriate key points. Should I break this out onto its own page? I thought it
made more sense this way...

>
> The last screen shot, Setup and Roster Panes, is too wide for the
> document.  The right portion is clipped.

The screen shots for the Comprehensive Programmer are big and wide. (around
830x598, give or take a pixel or two) There's a lot of "white space" (actually,
gray space) in the screens, but I didn't want to potentially confuse folks by
changing the way the screen looked. If a screen is clipped, there's a scroll bar
in it to get to the hidden part. (probably ought to add that to the manual,
too...)
Can your browser print at, say, 85-90% size? That should solve the problem.

The most extreme example of overly wide graphics is the Speed Control page.  I
_did_ scale the shots of the effects of the "curve" buttons down because no
essential information was lost - the shape of the curve was still evident. If I
scale the others, though, it makes it impossible to read the text.

> Now to get to what was asked about typo's etc.
>
> BTW is filker@m... the Joe Ellis recently of Orlando N'Trak fame?

That's me! What, you didn't recognise the BARR roadname in the roster screen?
<<grin>> Hi, Jerry!

>
> Cheers
>
>
> jerry snyder
> Orlando, FL

At 11:02 AM -0700 9/5/02, Mark Gurries wrote:
>Accidentally clicking on a programming mode button could lead to problems
>as well as  showing to much information is potentially confusing.  I
>would suggest that the program only show the current mode in real time.
>However, clicking on the MODE display window would take you to a dialog
>box  that shows you all the options and Defaults.  A note would tell
>people what this is about and suggest leaving it alone unless they know
>what they are doing.  Naturally there would be a cancel button to clear
>the window without changing anything.

So in place of the existing line of radio buttons, the identification
panel and the main (tabbed) programming panel would have a bottom
line that looked like

       Paged programming mode  (Set...)

where the (Set...) is a button, and the rest is text which could say
"Register programming mode", "Direct byte programming mode", etc.
Clicking the button pops a dialog box with some explanatory text and
the option radio boxes, plus "OK" and "Cancel" buttons which do the
obvious thing.

That's a straight-forward change in the code, and I'm happy to make
it if people think it an improvement.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

At 6:11 PM +0000 9/5/02, barr_ceo wrote:
>
>The most extreme example of overly wide graphics is the Speed
>Control page.  I _did_ scale the shots of the effects of the "curve"
>buttons down because no essential information was lost - the shape
>of the curve was still evident. If I scale the others, though, it
>makes it impossible to read the text.
>

On MacOS X, Windows and Linux, the size of some of the fonts is
shrunk to make that page fit better.  Unfortunately, the method used
to shrink fonts isn't available on original Macintosh and OS/2.
(That's the bug that was causing your crash in 1.0.5).  I've gotten
some advice on a different shrinking method that should work for
those, and hope to try it in 1.0.7 by early next week.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

--- In jmriusers@y..., "Jon Miller" <atsf@i...> wrote:
> Joe,
>     Do you think Bob's discussion on decoder modes would be good to add to
> the manual or just confusing?  If added it probably would go with "How to
> select the right decoder programmer"  Your thoughts?
>
> Jon Miller

Only in a very simplified form. Most users don't need to know _why_ something
is, just how to use it and when. For me, having enough information to write
clear instructions is important. I _think_ I've got that now. I'll write
something up and get it into the next update (probably late tonight or
tomorrow...)

I'm glad I'm doing this in HTML, and broken into pages. It's becoming more
obvious that I'm aiming at a quickly moving target, and I'm better off with a
shotgun than a rifle! <<grin>>

PULL!! <<blam blam blam....>>

You're doing a great job Joe, maybe a double barrel 10 gauge :).

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

At 9:17 AM -0700 9/5/02, Bob Jacobsen wrote:
>[  ...  ]
>Register mode is an extension of address mode. You literally cannot
>have register mode without address mode, as a write to the short
>address in register mode is an identical sequence to an address mode
>write.  But register mode only allows you to change a few things, not
>all the various CVs.  There are some older register-mode-required
>decoders still being sold, mostly from MRC and Wangrow.  And a _lot_
>of people have them!
>
>[  ...  ]

It's been so long since I thought about this stuff I've probably got
it wrong.  The two really old (pre-DCC standard!) Lenz decoders I have
installed in the boxcab (#36) and the MDC Consolidation (#32) probably
do not have more than one programming mode.  IIRC you poked at them one
evening to add to the list.  FWIW.




            --+---+   \/ 	 -bill
       ++---+ |[]]|_^_[] 	 steamloco2001@...
      _|____+-+___|____|_  Concord, CA
      | o+o +-+ <>--<>-= \

OK... Spelling corrected, incorporated Programming Mode explanations,
and reformatted things so that all the graphics are in a separate
folder so I don't get confused so easily...

"Nuff.  I'm going to bed. <<grin>>

Gotta re-build a Saxophone this weekend, so that will keep me pretty
busy. Probably won't do any more updates of the Manual until V1.0.7...
I'm expecting to have to redo a bunch of screen shots for that one if
Bob incorporates the Programming Mode changes he was talking about.