|
Locked
Re: Q about programming modes (was Re: New file uploaded to jmriusers)
At 2:30 PM +0000 9/5/02, barr_ceo wrote:
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) |
|
Locked
Re: 1.0.5 version in two forms
At 5:23 AM +0000 9/3/02, barr_ceo wrote:
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) |
|
Locked
Re: 1.0.5 version in two forms
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 I think I've got this fixed in the 1.0.6 version. You can try downloading that from: 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) |
|
Locked
JMRI/DecoderPro 1.0.6 test version for Windows, Macintosh
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: MacOS X: Windows: 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) |
|
Locked
Re: 1.0.5 version in two forms
At 4:54 PM -0400 8/30/02, jerry snyder wrote:
I'm puffing pretty hard trying to catch on to what's up with JMRI. I haveHow you update depends on which type of computer you've got. If it's some form of Windows, just run the .exe file. If you're using Linux, Macintosh or OS/2, the .exe file isn't going to do you any good. Instead, you take the .zip file, unpack it to create a folder, and move the files into place by hand. Hopefully I'll be able to create a Macintosh installer to automate that process Real Soon Now, but I don't know how to do that for Linux or OS/2. Note that the 1.0.5 update et al is really intended for testing; as you've seen in the Yahoo group, those updates occasionally backfire for some people. And I'm lost. Can you point me to someplace that can give me an overviewThe best overview we've got is: or for the DecoderPro part: For installing the original program, but not the update, please see: It would be great if somebody wanted to write some better documentation. A manual, even a very basic one, would be _really_ great. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
|
Locked
Re: 1.0.5 version in two forms
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 toOops. My mistake. The Mac "classic" version of Java uses an older set of libraries. The code to put "little" editable numbers on the speed table sliders uses a routine that's not present in this older version, hence the error. I didn't catch this in testing, sorry. I'll protect against the error, retest on an older Mac and get an update out shortly. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
Bob Jacobsen