|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21244 Location: Chicago, IL |
Posted: Tue Oct 07, 2003 2:59 pm Post subject: FYI: 6805 protocols |
|
|
MikeE has noticed that there are two types of 6805 protocol out there, not one as we had previously assumed.
Mike can fill you in on the details, I'm just throwing this out there so that any of you maintining IR, RM, KM, etc can start allowing for a new protocol type. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Oct 14, 2003 11:47 am Post subject: |
|
|
I'm still wondering how we are going to denote the difference in the protocols in the RDF files (for RM's benefit). The problem is not dissimilar to the old/new S3C8 types, which got me thinking aboout how that was addressed.
Basically, the RAMAddr=nn setting is used to differentiate between the two S3C8s, since IR only needed to know how to disassemble the protocols. While this works OK, it's not the most reliable method of indicating a fundamental difference in the protocol construction.
Again, this has no direct impact on IR, so I am proposing that we add a new item to the [General] section to indicate the protocol type. IR would simply ignore this new item, so Mark Pauker would not have to do anything to IR to encompass this change.
My suggestion for the new item is "ProtocolClass=xyzabc", but I'd be happy with any other name that makes us all happy.
So, the RDF would look something like this:
Code: | [General]
Name=Radio Shack 15-1925 / 15-1918 / 15-1919 6-in-1
EepromSize=$400
AdvCodeAddr=$021..$0DB
FavKey=$14, $0DD, 10, 3, 1
UpgradeAddr=$100..$3FC
Processor=6805
ProtocolClass=SW
RDFSync=3
ImageMap=15-1925.map
|
RM would use this as a default protocol variant for all protocols, having much the same effect as Greg's prior proposal to append the variant name in the [Protocols] section. _________________ Mike England |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21244 Location: Chicago, IL |
Posted: Tue Oct 14, 2003 12:02 pm Post subject: |
|
|
I like the idea, however, I think a better name might be ProcessorVersion or ProcessorVer as this makes the link to Processor more obvious.
We should then also include something in the S3C8 RDFs to differentiate between the two versions. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
jamesgammel Exile Island Resident
Joined: 03 Aug 2003 Posts: 394 Location: Gillette, Wyoming |
Posted: Tue Oct 14, 2003 12:28 pm Post subject: |
|
|
I gather from Mark Pierson's KM post that apparantly some 6805's use a different 6805 processor chip, so there's ar least two, possibly three(?) different 6805 processors?
As noted in my various posts about the Mill4, i discovered that the B00 and B01 use epoxy blob processors, and the B04 uses a "normal'chip. I was able to find that it can be discerened without taking the remote apart
Can one discern which of the 2 or 3 different 6805's his particular remote has without having to take it apart? IE do all B00's have a common processor, whereas a B02 or B04, or whatever always uses a different one?
Looking at Kent's Intuitive pix at his site, It can be seen that his "B01" uses a "normal" chip (no epoxy blob). Since no one has indicated that he has a "B00" version, I guess we don't know yet if it exists as a model, nor what chip it uses if it does exist. I assume from what I've seen and noticed so far that the signatures are identical, regardless of the processor chip (like the Mill4)?
Jim |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Tue Oct 14, 2003 12:47 pm Post subject: |
|
|
I don't know about IR, but RM uses the processor information to detemine:
1. Determining what protocols have protocol upgrade code compatible with a given remote.
2. Which protocol upgrade code to use for a given remote, and if it should be translated.
For RM it would be just as effective to embed the processor version in the processor, as opposed to adding an additional parameter.
So, instead of
Processor=6805
ProcessorVersion=C9
We would have
Processor=6805-C9
In protocols.ini, we would need to create separate entries for the protocol upgrade code, which would somehome combine the processor and version in much the same way.
Code.6805-C9=...
Code.6805-RC16/18=... _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Oct 14, 2003 5:55 pm Post subject: |
|
|
gfb107 wrote: | I don't know about IR, but RM uses the processor information to detemine:
1. Determining what protocols have protocol upgrade code compatible with a given remote.
2. Which protocol upgrade code to use for a given remote, and if it should be translated.
| Which is exactly why I'm concerned with letting RM know what protocols it should choose. gfb107 wrote: | For RM it would be just as effective to embed the processor version in the processor, as opposed to adding an additional parameter.
So, instead of
Processor=6805
ProcessorVersion=C9
We would have
Processor=6805-C9
| I agree that it is just as effective, but the only problem is that IR would have to be modified to recognize (read: hard-coded) specific processor-type codes, or at least to ignore the version. My whole reason for suggesting a second parameter was to allow control of RM without requiring IR to change. Perhaps it would be a small change this time, but it's already difficult keeping the two programs compatible with the RDFs, and if there are enough small things like this, it'll become impossible.
I don't think it would do any harm to allow the second parameter. Internally, you could just append it to the basic processor type if you like, so we'd have the option to use it or not. _________________ Mike England |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Oct 14, 2003 6:21 pm Post subject: |
|
|
jamesgammel wrote: | I gather from Mark Pierson's KM post that apparantly some 6805's use a different 6805 processor chip, so there's ar least two, possibly three(?) different 6805 processors?
As noted in my various posts about the Mill4, i discovered that the B00 and B01 use epoxy blob processors, and the B04 uses a "normal'chip. I was able to find that it can be discerened without taking the remote apart
Can one discern which of the 2 or 3 different 6805's his particular remote has without having to take it apart? IE do all B00's have a common processor, whereas a B02 or B04, or whatever always uses a different one?
Looking at Kent's Intuitive pix at his site, It can be seen that his "B01" uses a "normal" chip (no epoxy blob). Since no one has indicated that he has a "B00" version, I guess we don't know yet if it exists as a model, nor what chip it uses if it does exist. I assume from what I've seen and noticed so far that the signatures are identical, regardless of the processor chip (like the Mill4)?
Jim | I don't think it's possible to make a hard-and-fast rule about determining the processor type just by looking at the packaging.
So far, the 6805-based remotes we have examined physically are using a 40-pin chip for the older (SW) types, and a 28-pin chip for the newer (HW) type. However, this does not help if you find an epoxy blob on the PCB, and it is certainly possible that there are other remotes out there that we have not seen which violate this "rule".
It is most likely that the EEPROM signatures can be associated with a specific version of the ROM code inside the CPU chip. However, there are many cases where UEI's Bxx revision codes do not indicate a change in the CPU code. For example, the URC-44000B02 and URC-44000B04 Navigators use the same signature (and the same ROM code inside identical CPU chips). If someone comes across a B03 version, I would not be surprised to find it is also identical in all these respects. _________________ Mike England |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|