JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Pause protocol on URC-7555 (HCS08 processor)??
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Mon Oct 19, 2009 7:23 am    Post subject: Reply with quote

mr_d_p_gumby wrote:
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.)

I've just done a test on the URC-7781 and if you omit that RAMAddr entry then disassemblies start at $0000, not $0100. I could change that in IR.exe, but having just posted the final version of IR 8.01, it would not get into a release for quite some time.
_____________
Graham
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 361

                    
PostPosted: Mon Oct 19, 2009 9:14 am    Post subject: Reply with quote

mathdon wrote:
I could change that in IR.exe, but having just posted the final version of IR 8.01, it would not get into a release for quite some time.

I was waiting for Graham to "weigh in" on this before commenting. I just checked the "latest 'n' greatest" set of RDFs that Nils emailed me. There are only 27 HCS08 RDFs, so it's not a back-breaking job for me to change them all one way then change them all back if/when the next version of 'IR.exe' is altered to default to $0100 as the disassembly base address.

I'm OK with whatever we do and I'm sensing that Graham is OK with whatever I do, so Mike, I'm going to defer to your experience (which is the euphemism for "I'm laying this decision on your shoulders" Wink).... Which of the following should I do?:
  1. Nothing
  2. Change all HCS08 RDFs to use "RamAddr=$0100", including adding the line where it's currently missing
  3. Delete the "RamAddr=" lines from all HCS08 RDFs, letting the disassembly base address default to $0000 until 'IR.exe' is altered to use $0100
FWIW, I vote for the 2nd option for now. It goes against what the RDF spec dictates, but it seems the most practical for now.

Bill
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Mon Oct 19, 2009 10:04 am    Post subject: Reply with quote

I agree. The 2nd option seems like the most practical at this point.

I would also go ahead and change IR in the next release to default to $0100 for the HCS08 (and the two HC05 types if it is not already doing so).
_________________
Mike England
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 361

                    
PostPosted: Mon Oct 19, 2009 10:22 am    Post subject: Reply with quote

mr_d_p_gumby wrote:
I agree. The 2nd option seems like the most practical at this point.
OK, that's what I'll do then. Thanks for the input, Mike.

Bill
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Tue Oct 20, 2009 2:07 pm    Post subject: Reply with quote

I've now checked the use of the RAMAddr entry by IR.exe. It is used to distinguish between S3C8 and S3C8+ for displaying the processor name and setting default pause parameters, but otherwise it is only used as the start address for disassembly. If this RDF entry is omitted, it defaults to $0000. So at present, if we follow the RDF Spec and remove the RAMAddr entry for everything other than the S3... processors, the disassembly for all other processors will start at $0000.

The proposal is to change this default to $0100 for HCS08 and the HC05 types. So I have two questions:

a) Mike mentions "the two HCS05 types", but from other info from him there seem to be three, 6805RC16/18, 6805C9 and SST65. Should all three have RAMAddr = $0100?

b) That leaves the 740 processor. Should that stay with the current default ot RAMAddr = $0000?

There is also a third, separate, question. Should I make IR.exe ignore the RAMAddr entry if Processor is set to other than an S3... type, or should I leave things as they are, so that users/developers can use a different base value for disassembly if they wish?

I've also just noticed the following quote, and so will reply in this thread though a new one has been started for the RDF release:

WagonMaster wrote:
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?

I think that at present, all RDFs should be "RDF4 spec but RDF3 compatible". This means (see the RDF4 Spec) that all RDF4 features can be included but in certain cases there have to be two sets of entries, eg a [SpecialProtocols] section but also a [SpecialProtocols+] section. We are not yet ready to move to pure RDF4 spec, as that can break RDF3-only apps, and we lose nothing by retaining RDF3 compatibility other than needing this duplication of certain entries.
________________
Graham
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Tue Oct 20, 2009 3:33 pm    Post subject: Reply with quote

mathdon wrote:
a) Mike mentions "the two HCS05 types", but from other info from him there seem to be three, 6805RC16/18, 6805C9 and SST65. Should all three have RAMAddr = $0100?
The SST65 chip is essentially a 6805RC16/18 with added functionality for its flash memory capabilities, so it should be treated the same.
mathdon wrote:
b) That leaves the 740 processor. Should that stay with the current default ot RAMAddr = $0000?
The P8/740 also has special page 0 instructions & registers, so $0000 is not a great choice. I use $0132 as a base address in PB because that is where protocols are loaded in all the 740 remotes that I know about. $0100 would not be a bad default either, if that is easier for you.
mathdon wrote:
There is also a third, separate, question. Should I make IR.exe ignore the RAMAddr entry if Processor is set to other than an S3... type, or should I leave things as they are, so that users/developers can use a different base value for disassembly if they wish?
The original intent was that it be ignored, but I can see the value in leaving it as-is. I think it would be safe to leave it alone as long as it is ignored for non-S3C8 types for anything other than base address.
_________________
Mike England
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 361

                    
PostPosted: Tue Oct 20, 2009 5:06 pm    Post subject: Reply with quote

mathdon wrote:
I think that at present, all RDFs should be "RDF4 spec but RDF3 compatible". This means (see the RDF4 Spec) that all RDF4 features can be included but in certain cases there have to be two sets of entries, eg a [SpecialProtocols] section but also a [SpecialProtocols+] section. We are not yet ready to move to pure RDF4 spec, as that can break RDF3-only apps, and we lose nothing by retaining RDF3 compatibility other than needing this duplication of certain entries.

Sounds logical to me. I need to get smarter about exactly what RDF v4 entails, so I may have some more questions about this, but for now, all sounds good to me. Smile

Bill
Back to top
View user's profile Send private message
Capn Trips
Expert


Joined: 03 Oct 2003
Posts: 3990

                    
PostPosted: Tue Oct 20, 2009 5:08 pm    Post subject: Reply with quote

Silly question, but ought this discussion be in the "Beginners'" forum? It might scare a true Beginner off!
_________________
Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!


Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer)
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Tue Oct 20, 2009 7:30 pm    Post subject: Reply with quote

Capn Trips wrote:
Silly question, but ought this discussion be in the "Beginners'" forum? It might scare a true Beginner off!
Capn, you've discovered our secret plan! Twisted Evil
_________________
Mike England
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Wed Oct 21, 2009 10:46 am    Post subject: Reply with quote

mr_d_p_gumby wrote:
mathdon wrote:
There is also a third, separate, question. Should I make IR.exe ignore the RAMAddr entry if Processor is set to other than an S3... type, or should I leave things as they are, so that users/developers can use a different base value for disassembly if they wish?
The original intent was that it be ignored, but I can see the value in leaving it as-is. I think it would be safe to leave it alone as long as it is ignored for non-S3C8 types for anything other than base address.

In the end I think it better to ignore the RamAddr entry for processors other than S3... series. It certainly is more consistent to do so, as there is no freedom in its value for the S3 processors so it seems better that there should not be for the others, either. So what I will do, if no-one objects, is

a) For the S3C80 processor family, make the entry a required one and give an error message if the value is other than $8000 or $FF00;

b) For the S3F80 family, make it optional, defaulting to $FF00 and giving an error if set to anything other than $FF00;

c) For the HCS08 and HC05 families, ignore the entry and use $0100 as start address for disassemblies;

d) For the 740 processor, ignore the entry and use $0132 as the start address for disassemblies.

Of these b) is the odd one. I would have chosen to ignore the entry, but the RDF spec says RamAddr is used only when Processor=S3C80 or S3F80, so I feel it should be checked even if there is only one legal value.

Is this OK?
_____________
Graham
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 361

                    
PostPosted: Wed Oct 21, 2009 1:02 pm    Post subject: Reply with quote

mathdon wrote:
Is this OK?

For the record, it's fine with me. But, of course, Mike's opinion is the one that carries far more weight on this issue. I'm OK with whatever you guys conclude and will adjust the RDFs accordingly.

Bill
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Wed Oct 21, 2009 3:16 pm    Post subject: Reply with quote

mathdon wrote:
Is this OK?
I could live with that. The only change I would make is to not force the entry to be there for S3C80 types, and to default to $8000. That would maintain the original intent.
_________________
Mike England
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Wed Oct 21, 2009 4:38 pm    Post subject: Reply with quote

mr_d_p_gumby wrote:
The only change I would make is to not force the entry to be there for S3C80 types, and to default to $8000. That would maintain the original intent.

OK, will do.
_____________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control