 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
 Posted: Sat Oct 17, 2009 12:21 am Post subject: |
 |
|
OK, excellent! Thanks for the confirmation.
Clearly I should find myself a Windows partition, install Excel, and run KM sometime. I wasn't aware of how it dealt with Special Protocols and it might help in future discussions if I understood it a bit better.
Bill |
|
| Back to top |
|
 |
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Sat Oct 17, 2009 6:17 am Post subject: |
|
|
| Quote: | | Clearly I should find myself a Windows partition, install Excel, and run KM sometime. I wasn't aware of how it dealt with Special Protocols and it might help in future discussions if I understood it a bit better. |
AFAIK, the only special protocol handled this way is the Pause protocol, and RM handles the Pause(special) the same way. The problem here was that RM doesn't have the code for the JP1.2 remotes, so it doesn't list it when a JP1.2 remote is selected.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sat Oct 17, 2009 10:21 am Post subject: |
|
|
I haven't been following this, but I would like to explain something about the disassembly of HCS08 protocols as shown in IR.exe that puzzled me for a LONG LONG TIME, in case it helps. I thought I was going crazy and that I would never be able to understand protocol code until this LIGHT SUDDENLY DAWNED!
The issue: Jumps into nonsensical places within the protocol code, such as to the middle of some other instruction.
The light that dawned: IR.exe disassembles protocol code as if it were to be executed at $FF00. It isn't. $FF00 is in the middle of the protected part of the ROM. So if you have a Branch instruction that decodes as, say BRA $FF1A then it goes to $FF1A within the protocol listing, since the machine instruction carries a relative address. If you have JMP $FF1A then it goes to $FF1A within the ROM, a quite different location, as the machine instruction carries an absolute address.
Why $FF00? Presumably because that is suitable for S3C8 processors but it is crazy for HCS08 ones.
______________
Graham |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sat Oct 17, 2009 11:40 am Post subject: |
|
|
| mathdon wrote: | | Why $FF00? Presumably because that is suitable for S3C8 processors but it is crazy for HCS08 ones. |
I agree! IIRC, the 6805 disassemblies in IR use $0100 as a base address, and I think the HCS08 should be the same. Some of the newer executors are more than 256 bytes in length, and using $FF00 will have the code falling off the edge of the world at $FFFF.
_________________
Mike England |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Sat Oct 17, 2009 1:28 pm Post subject: |
|
|
Thanks for your inputs, Graham -- always appreciated!
Actually, the difference between a relative jump and an absolute jump doesn't confuse me a bit (and hasn't -- for more years than I'm willing to admit  ) but I'll never complain about someone like you providing useful supplemental comments.
Even the jump into the nonsensical spot didn't really phase me, but I thought I'd ask for clarification -- before I surmised the answer myself with the assembly manual.
But the disassembly "base address" issue I was not aware of, so that's very useful to know. As for the address to display, I'm sort of thinking it should either be $0000 (preferred choice) or the actual address from which the 'pause' Special Protocol code actually executes (which, based on this new information, I'm guessing would be somewhere directly from the "UpgradeAddr" area [i.e. $0200..$03FF, for the URC-x820], correct?). In fact, for the S3C80 (et al) microcontrollers, why use $FF00? My ignorance is showing here, but why is that appropriate? The SP code doesn't actually execute from there, does it?
One thing I still don't know: what is the purpose of those few data bytes at the start? I'd probably have figured this out for myself eventually, but as long as I've conveniently got your attention, it can't hurt to ask, right? 
| mathdon wrote: | | $FF00 is in the middle of the protected part of the ROM. |
Given your expertise in this (and so many other) area(s), I don't doubt what you say. But why does the RDF for the URC-x820 (HCS08-based) remotes have this line?:
Oh, wait... I just answered my own question. The RDF v4 specification document says this about the "RamAddr" entry:
| RDF v4 spec wrote: | | This entry is used only when Processor=S3C80 or Processor=S3F80; it should be omitted otherwise. |
So it's a "bug".
Based on that erroneous line in the URC-x820 RDF, I was under the erroneous assumption that $FF00 was truly RAM on the HCS08 and based on the 'IR.exe' disassembly showing that address, I assumed that the special protocol may have somehow been copied there to execute. Of course, based on what you say, I can see now that this is all wrong.
So do I PM Nils Ekberg to get the RDF fixed or does he just do the aggregation? While I'm on that topic, one thing I've thought for a long time is that every RDF should have a comment block header with the name (and maybe a contact method, even if it's just their JP1 nickname) of the author(s) (and maybe a changelog). Without that info, I don't know who to contact to get this RDF fixed.
Side rant: The RDF spec says "There is no official method for adding comments to an RDF file." This seems like an important shortcoming to me and something that we should change.
Sorry that this thread has drifted a bit far from its original purpose. If I'd had any idea beforehand, I'd have started a new thread!
Bill |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sat Oct 17, 2009 4:22 pm Post subject: |
|
|
| WagonMaster wrote: | | But the disassembly "base address" issue I was not aware of, so that's very useful to know. As for the address to display, I'm sort of thinking it should either be $0000 (preferred choice) or the actual address from which the 'pause' Special Protocol code actually executes (which, based on this new information, I'm guessing would be somewhere directly from the "UpgradeAddr" area [i.e. $0200..$03FF, for the URC-x820], correct?). |
I'd stick with $0100. That's the base address I've used in Protocol Builder for the HCS08, and it is not entirely arbitrary. The area below $0100 is full of hardware registers and is usually where the stack is located. The older HC05 remotes also loaded protocols in that area. | WagonMaster wrote: | | In fact, for the S3C80 (et al) microcontrollers, why use $FF00? My ignorance is showing here, but why is that appropriate? The SP code doesn't actually execute from there, does it? |
Yes it does, and in fact all protocols, resident or upgrade, execute from there. The HCS08 remotes are unique in that they can execute a protocol in-place. All of the other remotes first load the protocol into RAM, and execute it there. In the S3C8+ processor, RAM is mapped to address $FF00. The older S3C8 had RAM at $8000. The HC05 remotes loaded them into RAM somewhere around $0100, though it varies, and some load them at $0107, for example. | WagonMaster wrote: | | One thing I still don't know: what is the purpose of those few data bytes at the start? I'd probably have figured this out for myself eventually, but as long as I've conveniently got your attention, it can't hurt to ask, right? |
No problem Those bytes are a required header structure that the remote expects to be there. For the HCS08, the first 2 bytes are expected to be a relative branch instruction ($20 xx). This is followed by two bytes which define the IR carrier frequency & duty cycle. Next is a byte which tells the remote how many fixed (device) bytes and variable (command) bytes are used by the protocol. After that, a series of one or more "flag" bytes tell the IR engine what features are needed. Finally, another series of data bytes give the IR engine some parameter values. Not all of this is always present, as it depends on what the protocol requires. In the case of the pause protocol, we need only the branch instruction and the first three bytes, since it does not call the IR engine.
I wrote all the pause protocols that are in KM, except for the original S3C8+ version. I made them all use the same timing arguments. Here is my original source for the HCS08 pause protocol that is in KM: | Code: | BRA LOOP
DB $00,$00 ;no carrier
DB $01 ;0 dev, 1 cmd
LOOP: LDA #$F4 ;AX arg to FFA1 call
LDX #$29 ;approx 62.5mS
JSR $FFA1 ;delay per AX
DBNZ DCBUF,LOOP ;bump counter, loop if not done
RTS |
| WagonMaster wrote: | | mathdon wrote: | | $FF00 is in the middle of the protected part of the ROM. |
Given your expertise in this (and so many other) area(s), I don't doubt what you say. But why does the RDF for the URC-x820 (HCS08-based) remotes have this line?:
Oh, wait... I just answered my own question. The RDF v4 specification document says this about the "RamAddr" entry: | RDF v4 spec wrote: | | This entry is used only when Processor=S3C80 or Processor=S3F80; it should be omitted otherwise. |
So it's a "bug". |
You are correct. It should not have been present in this RDF. | WagonMaster wrote: | | So do I PM Nils Ekberg to get the RDF fixed or does he just do the aggregation? |
It wouldn't hurt. We are certainly long overdue for an RDF update, and not just for this particular one. In the past, Nils has gone over each RDF to make sure it conforms and has all the proper entries before releasing the entire package. I'm not sure if he has the time of late to devote to this, and the number of RDF files has increased since his last release, so it's become a much bigger project. (Do I hear you volunteering to take this over?  ) | WagonMaster wrote: | While I'm on that topic, one thing I've thought for a long time is that every RDF should have a comment block header with the name (and maybe a contact method, even if it's just their JP1 nickname) of the author(s) (and maybe a changelog). Without that info, I don't know who to contact to get this RDF fixed.
Side rant: The RDF spec says "There is no official method for adding comments to an RDF file." This seems like an important shortcoming to me and something that we should change. |
I also wrote the RDF spec document, but don't blame me for this one. I'm just the messenger!
Seriously, to get an official comment syntax method defined, we'd need agreement from those currently developing IR.exe and RM/RMIR (Graham and Greg, respectively). From a practical standpoint, we'd need to do it in a way that does not make older version of IR puke, since users don't seem to always upgrade to the latest version despite our best efforts. We'd also have to try to maintain compatibility with the various versions of Extinstall which use a much smaller part of the RDF file.
_________________
Mike England
Last edited by mr_d_p_gumby on Sat Oct 17, 2009 4:54 pm; edited 1 time in total |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sat Oct 17, 2009 4:48 pm Post subject: |
|
|
| gfb107 wrote: | | I'll include this in the next release of RM. |
Greg, here's what should be in the Pause protocol entry: | Code: | Code.S3C80=00 00 01 28 03 C6 C0 00 00 0A FE 1A FC 2A FA AF
Code.HCS08=20 03 00 00 01 A6 F4 AE 29 CD FF A1 3B 60 F6 81
Code.6805-RC16/18=00 00 01 CD 01 8F A6 51 CD 01 95 3A 50 26 F7 81
Code.6805-C9=00 00 01 CD 01 92 A6 51 CD 01 9E 3A 50 26 F7 81
Code.740=00 00 01 A5 5D A0 50 22 42 16 D0 F9 60 |
| WagonMaster wrote: | | Clearly I should find myself a Windows partition, install Excel, and run KM sometime. I wasn't aware of how it dealt with Special Protocols and it might help in future discussions if I understood it a bit better. |
It would also give you a way to use PB (protocol builder), which would give you much more insight into how protocol executors work.
_________________
Mike England |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Sat Oct 17, 2009 6:16 pm Post subject: |
|
|
Wow... what a great set of thorough, lucid information!!! A thousand "Thank You"s for clearing this up for me, Mike!
| mr_d_p_gumby wrote: | | I'd stick with $0100. |
Roger that. I rescind my earlier suggestion in light of your superior reasoning and experience, good sir.
| mr_d_p_gumby wrote: | | Those bytes are a required header structure that the remote expects to be there. |
OK, excellent. I'm very glad now that I asked. Who knows how long it might've taken me to figure those details out on my own?  That info is all very helpful.
BTW, I've never used Protocol Builder, but based on your advice, I'll definitely be giving it a try.
| mr_d_p_gumby wrote: | | We are certainly long overdue for an RDF update |
I'll address the RDF issues in a new thread, since I've already unintentionally abused this one enough. By the way, no blame from me on any of the RDF issues. That's a friendly rant from me. The RDF specification is a great, well-written source of a lot of my best information when trying to figure out some of these mysteries.
Thanks again for all that information, Mike! I really appreciate you taking the time to educate me on these finer points.
Bill |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sun Oct 18, 2009 4:40 am Post subject: |
|
|
| WagonMaster wrote: | | Actually, the difference between a relative jump and an absolute jump doesn't confuse me a bit (and hasn't -- for more years than I'm willing to admit ) |
I never for a moment thought it did, but have you ever come across the same address meaning different places depending on whether it was a relative or absolute jump? The really confusing thing is when the absolute address is within the address range of the displayed disassembly. If you would immediately realise under those circumstances that it didn't mean go to that point in the protocol code, but to the point in ROM with the same address, then you're a better man than I am! 
| WagonMaster wrote: | | mathdon wrote: | | $FF00 is in the middle of the protected part of the ROM. |
Given your expertise in this (and so many other) area(s), I don't doubt what you say. But why does the RDF for the URC-x820 (HCS08-based) remotes have this line?:
Oh, wait... I just answered my own question. The RDF v4 specification document says this about the "RamAddr" entry:
| RDF v4 spec wrote: | | This entry is used only when Processor=S3C80 or Processor=S3F80; it should be omitted otherwise. |
So it's a "bug".
|
Actually, it is that line in the RDF that makes disassemblies start at $FF00. If you change it to $0100 then they will start at $0100. So the line is useful even for HCS08 processors and the RDF4 Spec shouldn't quite say what it does. I've never made this change in my RDFs (those for the URC-7781 still have it, inherited from the URC-7780 RDF) as I haven't been absolutely sure that it doesn't have some other significance, if not for IR.exe (which I can check) but for RM or some other application that uses RDFs.
| WagonMaster wrote: | | Side rant: The RDF spec says "There is no official method for adding comments to an RDF file." This seems like an important shortcoming to me and something that we should change. |
I've always been puzzled by what applications are broken if a comment line starting with a # is put in. I thought all apps ignored RDF lines with keys they didn't understand. That, after all, is how we can add new keys to the RDF spec without breaking old apps - it's only adding new syntax to old keys, as in the RDF3 to RDF4 change - that can break apps. So can someone enlighten me on why starting a comment line with # is not a safe thing to do?
__________________
Graham |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Sun Oct 18, 2009 8:04 am Post subject: |
|
|
| mathdon wrote: | | I never for a moment thought it did, but have you ever come across the same address meaning different places depending on whether it was a relative or absolute jump? |
Not in recent memory, but I'm sure I must have at some time in the past, so I certainly see your point. I just don't deal with assembly much anymore. There's a part of me (the "sick" part? ) that actually misses it somewhat.
| mathdon wrote: | | The really confusing thing is when the absolute address is within the address range of the displayed disassembly. |
I guess I tend to subconsciously pay attention to the instruction's size in bytes (i.e. 1, 2, or 3 bytes), making a relative jump distinct from an absolute jump, showing the different intent.
| mathdon wrote: | | If you would immediately realise under those circumstances that it didn't mean go to that point in the protocol code, but to the point in ROM with the same address, then you're a better man than I am! |
In the JP1 world, I won't be making that claim anytime soon, be assured, my friend!
| mathdon wrote: | | Actually, it is that line in the RDF that makes disassemblies start at $FF00. If you change it to $0100 then they will start at $0100. So the line is useful even for HCS08 processors and the RDF4 Spec shouldn't quite say what it does. |
Very interesting... that possibility never even occurred to me. OK, so assuming that Nils Ekberg doesn't mind giving up maintainership of the RDFs for this next cycle, what should I do? (BTW, a quick check last night found 13 more RDF files that have the same "bug".) Do I convert all the HCS08 RDFs to use $0100 (even adding the line where it's not present?) and/or do we fix the RDF spec to describe the dual purpose of the "RamAddr" line?
P.S. I opened a new thread for the "RDF Comments" issue. If you could, please discuss that issue over there since I've already taken this thread so far out of its way, we'll need a map to get back!
Bill
Last edited by WagonMaster on Sun Oct 18, 2009 2:02 pm; edited 1 time in total |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Sun Oct 18, 2009 10:42 am Post subject: |
|
|
| mr_d_p_gumby wrote: | Greg, here's what should be in the Pause protocol entry: | Code: | Code.S3C80=00 00 01 28 03 C6 C0 00 00 0A FE 1A FC 2A FA AF
Code.HCS08=20 03 00 00 01 A6 F4 AE 29 CD FF A1 3B 60 F6 81
Code.6805-RC16/18=00 00 01 CD 01 8F A6 51 CD 01 95 3A 50 26 F7 81
Code.6805-C9=00 00 01 CD 01 92 A6 51 CD 01 9E 3A 50 26 F7 81
Code.740=00 00 01 A5 5D A0 50 22 42 16 D0 F9 60 |
|
Thanks!
_________________
-- 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: Sun Oct 18, 2009 12:33 pm Post subject: |
|
|
| mathdon wrote: | | Actually, it is that line in the RDF that makes disassemblies start at $FF00. If you change it to $0100 then they will start at $0100. So the line is useful even for HCS08 processors and the RDF4 Spec shouldn't quite say what it does. I've never made this change in my RDFs (those for the URC-7781 still have it, inherited from the URC-7780 RDF) as I haven't been absolutely sure that it doesn't have some other significance, if not for IR.exe (which I can check) but for RM or some other application that uses RDFs. |
The RDF Spec deliberately limits the use of the RAMAddr entry to S3C8/S3F8 processors. Originally, it's purpose was only to set the disassembly base address in IR. At the time, the universe consisted of S3C8 types, and RAMAddr was created when the S3C8+ processors came along. Over time this entry became an indirect way to differentiate between the two S3C8 types, and will by implication specify other characteristics, such as execution speed (ex: Pause protocol), protocol vector addresses, etc.
Later, when I helped MP add support for the two different types of HC05 remotes to IR, it could not be used to specify the difference, as both types loaded protocols at $0100. Mark did not see a reason for IR to know the difference, but RM needed to know, so Greg & I created the ProcessorVersion entry for RM. It would have made things more consistent if IR had been changed to use ProcessorVersion to determine the S3C8 type, but that was not done.
Would it really be useful to use the RAMAddr entry on the HC05 & HCS08 remotes? (IIRC, $0100 should be the default base address for HCS08 remotes in IR when the entry is omitted.) A distinct charateristic of the Motorola/Freescale 8-bit micros is that page 0 is special. It contains hardware registers & RAM, and can be addressed with shorter instructions, and is the only page where bit set/test instructions can be used. Historically, any other RAM is placed between page 0 and the start of ROM. My point here is that it is unlikely that there would be a need for any base address other than $0100.
I don't object to using RAMAddr for other processor types, but I wrote the RDF Spec that way because I do not have any degree of confidence that its presence wouldn't wrongly cause a program to apply S3C8+ characteristics to a non-S3C8 remote. I'm open to changing this if it seems worthwhile, but this would be another one of those uphill battles over compatibility with older program versions. Certainly, it could be allowed under RDF Spec v4 if everyone involved agrees.
_________________
Mike England
Last edited by mr_d_p_gumby on Sun Oct 18, 2009 12:59 pm; edited 2 times in total |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sun Oct 18, 2009 12:47 pm Post subject: |
|
|
| WagonMaster wrote: | | Very interesting... that possibility never even occurred to me. OK, so assuming that Nils Ekberg doesn't mind giving up maintainership of the RDFs for this next cycle, what should I do? (BTW, a quick check last night found 13 more RDF files that have the same "bug".) Do I convert all the HCS08 RDFs' to use $0100 (even adding the line where it's not present?) and/or do we fix the RDF spec to describe the dual purpose of the "RamAddr" line? |
Since the current set of RDF files still fall under RDF Spec v3 where it is not allowed, for now, at least, my suggestion would be to remove the RAMAddr entry from all current HCS08 RDF files. As I mentioned above, the default address should be $0100 when the entry is omitted, and this works just fine for all known HCS08 remotes.
_________________
Mike England |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Sun Oct 18, 2009 3:01 pm Post subject: |
|
|
| mr_d_p_gumby wrote: | | Since the current set of RDF files still fall under RDF Spec v3 where it is not allowed, for now, at least, my suggestion would be to remove the RAMAddr entry from all current HCS08 RDF files. |
If I assume that I'll be making a release of v3-compatible RDF files first, that sounds logical to me.
| mr_d_p_gumby wrote: | | As I mentioned above, the default address should be $0100 when the entry is omitted, and this works just fine for all known HCS08 remotes. |
I'm not sure if you know this or not, since the phrase "should be $0100" could technically be interpreted 2 ways, but the current version of 'IR.exe' will NOT use a base address of $0100 for an HCS08 disassembly display if the "RamAddr=" line is deleted. It will use $0000 (which I didn't know until moments ago, when I tried all 3 permutations of the line's presence/absence with values of $FF00/$0100, with 'IR.exe' v8.01rc9). So, 'IR.exe' would have to change if that's the behavior we ultimately seek. It's not a problem for me whatever you guys want to do, but I obviously do not speak for Graham.
EDIT: Not that anyone doubted Graham on this, but I forgot to mention that I confirmed this:
| mathdon wrote: | | If you change it to $0100 then they will start at $0100. |
Anyway, I won't be making any changes for a few days, so there's plenty of time to discuss this more before any time is wasted on my part.
Would the plan be for me to first release a set of RDFs that are spec-v3-compatible, with all the known updates to-date, then make spec-v4 changes (whatever that entails -- I'm going into this effort with ignorant enthusiasm ) and make another release?
Bill |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sun Oct 18, 2009 3:32 pm Post subject: |
|
|
| WagonMaster wrote: | | I'm not sure if you know this or not, since the phrase "should be $0100" could technically be interpreted 2 ways, but the current version of 'IR.exe' will NOT use a base address of $0100 for an HCS08 disassembly display if the "RamAddr=" line is deleted. It will use $0000 (which I didn't know until moments ago, when I tried all 3 permutations of the line's presence/absence with values of $FF00/$0100, with 'IR.exe' v8.01rc9). So, 'IR.exe' would have to change if that's the behavior we ultimately seek. It's not a problem for me whatever you guys want to do, but I obviously do not speak for Graham. |
Hmmm... I guess that's something that slipped through the cracks long ago. It was supposed to be the default for the two HC05 processors, and I assumed it would carry over to the HCS08 as well. That may well be an argument for having the RAMAddr entry then. I assume we would have heard about any issues by now, since the RDFs have had the entry in there for some time now.
The problem with using $0000 as the base is similar to having $FF00 as the base; if a protocol executor references any of the hardware registers or page 0 RAM, then it might appear to be referencing itself.
_________________
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
