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)
Bob Jacobsen