| View previous topic :: View next topic |
| Author |
Message |
wwwoholic
Joined: 28 Nov 2003
Posts: 117
Location: Toronto, Canada
|
 Posted: Thu Feb 05, 2004 6:29 pm Post subject: |
 |
|
| johnsfine wrote: | | In summary, making IR understand that upgrades can overflow into other unfilled areas would be both easier and more useful than having the RDF specify the extra upgrade areas. |
I've been playing with some java code for RM to do this (you gave one of the possible algorithms in one of the topics). So far no big progress, as the placer code needs pretty cumbersome definition of what is available in each remote, and the only logical place for this data is RDF. Still working on it... but there might be somebody who thinks less and does more. |
|
| Back to top |
|
 |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Thu Feb 05, 2004 6:54 pm Post subject: |
|
|
| wwwoholic wrote: | | So far no big progress, as the placer code needs pretty cumbersome definition of what is available in each remote, and the only logical place for this data is RDF. |
What am I missing here?
For all S3C80 non extender configs and most S3C80 extender configs, all the data you need is aready in the RDF and in quite simple form. Some extra RDF syntax to cover stranger shape extenders would also be easy. |
|
| Back to top |
|
|
wwwoholic
Joined: 28 Nov 2003
Posts: 117
Location: Toronto, Canada
|
| Posted: Fri Feb 06, 2004 3:45 am Post subject: |
|
|
| johnsfine wrote: | | For all S3C80 non extender configs and most S3C80 extender configs, all the data you need is aready in the RDF and in quite simple form. Some extra RDF syntax to cover stranger shape extenders would also be easy. |
OK, maybe I'm overcomplicating again. I went through all the docs on Yahoo and some source codes in attempt to create memory maps for different remotes. e.g. for my extended 2116 I come up with:
000 CheckSum (002-7FD)
001 ?
002..009 Remote ID (e.g. RS70RS70)
00A..027 ?
028 TimeAddr
?
032 FixedData = $14
033..0FF Extender code (205 bytes)
100..3FE Upgrade (767 bytes)
3FF ?
400 probably 00h to terminate learned
401..751 AdvCode (848 bytes)
752..7FD extender code? (172 bytes)
7FE..7FF ?
As you can see there are some question marks. And the only info available from RDF is: AdvCodeAddr=$401..$751 and UpgradeAddr=$100..$3FE. I didn't know what to do with the rest, and what else can be there in other remotes, so I decided to write some generic code which reads ini-stile file describing each block in memory and what can be done with it (e.g. fixed location vs. can be moved around). Yeah, I know... any normal hacker would just hard code one remote and then modify it to support another. Unfortunately, I'm not the one. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Fri Feb 06, 2004 7:07 am Post subject: |
|
|
| wwwoholic wrote: |
000 CheckSum (002-7FD)
001 ?
|
Checksum uses two bytes.
| wwwoholic wrote: |
002..009 Remote ID (e.g. RS70RS70)
00A..027 ?
028 TimeAddr
?
032 FixedData = $14
|
Look again at the part of the RDF that specifies where the setup code of each device mode is stored, and where the individual settings are stored. Usually you will find every byte from 00A through that fixed data item accounted for.
| wwwoholic wrote: |
100..3FE Upgrade (767 bytes)
3FF ?
400 probably 00h to terminate learned
|
That 3FE is a common error. Some upgrade areas end at 3FE, but most (including this one) end at 3FF. The RDF is just wrong (limiting the user to one less byte of upgrade than he could have).
| wwwoholic wrote: |
7FE..7FF ?
|
I have no clue what that extender uses that part of eeprom for. I assume it is something that wasn't worth making the RDF file represent.
In few cases (especially in 4K 6012's) an extender chops up the memory badly so there are significant unused chunks. Then it would be nice to have an RDF syntax for unused chunks, so the upgrade overflow logic could use those as well. |
|
| Back to top |
|
|
wwwoholic
Joined: 28 Nov 2003
Posts: 117
Location: Toronto, Canada
|
| Posted: Fri Feb 06, 2004 8:51 am Post subject: |
|
|
Thanks! I'm slowly getting there:
000..001 CheckSum (002-7FD)
002..009 Remote ID (e.g. RS70RS70)
00A..027 [DeviceButtons] 15 x 2-byte setup codes
028..029 TimeAddr 2-byte ?
02B..030 [Settings] 6 x 1-byte MySystem button groups
031 [General] FavKey ? what data stored here?
032 FixedData = $14
033..0FF Extender code (205 bytes)
100..3FF Upgrade (768 bytes)
400 probably 00h to terminate learned
401..751 AdvCode (848 bytes)
752..7FD extender code? (172 bytes)
7FE..7FF ?
Now, how about the same for all JP1 remotes?  Just kidding. From other topics I learned that this is pretty common picture, with major differences in number of devices and learning support.
| johnsfine wrote: | | Then it would be nice to have an RDF syntax for unused chunks, so the upgrade overflow logic could use those as well. |
Yes, definitely. However I would rather define it the other way: used chunks. I think [FixedData] section in RDF is pretty close to this. It can be modified to accept memory range on the left and empty value (or single byte to populate) on the right.
And speaking of fixed data, it might be interesting to allow copy/paste of extender's .hex file into [FixedData] section. This way there would be no need for pre-loading an extended image into IR before making new configuration. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Fri Feb 06, 2004 9:31 am Post subject: |
|
|
| wwwoholic wrote: | | However I would rather define it the other way: used chunks. I think [FixedData] section in RDF is pretty close to this. It can be modified to accept memory range on the left and empty value (or single byte to populate) on the right. |
I think it is much more error prone to require the RDF to identify ALL used areas and allow IR.EXE to overflow upgrades into unused areas. If the RDF writer makes a mistake, all may seem well. Then someone might hit the combination of upgrades that makes it blow up.
| wwwoholic wrote: |
And speaking of fixed data, it might be interesting to allow copy/paste of extender's .hex file into [FixedData] section. This way there would be no need for pre-loading an extended image into IR before making new configuration. |
I'd prefer to keep the distribution of RDF files independent from the distribution of extender .hex files.
One IR.EXE feature I've wanted (but it doesn't make my top ten) is the ability to include the name of the .hex file in the body of the RDF file, and have some rule for which sections of the eeprom image are controlled by the .hex file.
This would just affect the "new" command (maybe also the fill upper memory command, I'm not sure how that works). If the named .hex file is missing the new command would refuse to operate. If the named .hex file was present the new command would use that .hex file as the source for anything the .rdf doesn't tell it how to initialize. |
|
| Back to top |
|
|
DGG
Joined: 08 Dec 2003
Posts: 143
|
| Posted: Fri Feb 06, 2004 11:51 am Post subject: |
|
|
Re the memory map 2 posts above, earlier this week while experimenting using $34-39 for the entry to Pt 1 of the 8910 extender, I discovered that $39 got "clobbered" (I recall the original contents, $2E, was changed to $28, or maybe it was the other way around) - apparently by one of the remote subroutines called during button-press processing. Part 1 would "do its thing" on the first button press, but that location would get overwritten before Pt 2 returned control to Pt 1 and "hang" the extender. The other 5 bytes were unchanged
I didn't bother trying to isolate the culprit, I just moved the beginning of Pt 1 back to $40. But, if its helpful, I'll investigate further.
Don |
|
| Back to top |
|
|
wwwoholic
Joined: 28 Nov 2003
Posts: 117
Location: Toronto, Canada
|
| Posted: Fri Feb 06, 2004 12:13 pm Post subject: |
|
|
| I don't think we should investigate extender's behaviour here. After all this is the place where they got written. The goal of my questions was to get a clear picture of what is inside memory in terms of binary "chunks" that can be moved around or placed permanently across eeprom. Internal contents of each chunk is covered (in most cases) by IR and RM already. The only thing of importance I can see now is when one chunk has an address of another one stored inside (as in protocol upgrade table). In this case whatever distribution logic will toss chunks around it should also update these addresses. |
|
| Back to top |
|
|
DGG
Joined: 08 Dec 2003
Posts: 143
|
| Posted: Fri Feb 06, 2004 1:38 pm Post subject: |
|
|
| ????? Just trying to be helpful by pointing out that the area $33-39 may not be a good place for the extender (as proposed in the memory map above). |
|
| Back to top |
|
|
wwwoholic
Joined: 28 Nov 2003
Posts: 117
Location: Toronto, Canada
|
| Posted: Fri Feb 06, 2004 3:22 pm Post subject: |
|
|
| Apparently I just misunderstood you. I thought that area is changed by extender's code itself. Well, the memory map above was combined from different documents, one of which was the source of extender2. As extender obviously works, it's either I got addresses wrong or that byte change does not affect it. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
