Pause protocol on URC-7555 (HCS08 processor)??

Post by **mathdon** » Mon Oct 19, 2009 6:23 am

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

WagonMaster · Post by **WagonMaster** » Mon Oct 19, 2009 8:14 am

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"

).... Which of the following should I do?:

Nothing
Change all HCS08 RDFs to use "RamAddr=$0100", including adding the line where it's currently missing
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

mr_d_p_gumby · Post by **mr_d_p_gumby** » Mon Oct 19, 2009 9:04 am

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).

WagonMaster · Post by **WagonMaster** » Mon Oct 19, 2009 9:22 am

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

Post by **mathdon** » Tue Oct 20, 2009 1:07 pm

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

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue Oct 20, 2009 2:33 pm

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.

WagonMaster · Post by **WagonMaster** » Tue Oct 20, 2009 4:06 pm

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.

Bill

Capn Trips · Post by **Capn Trips** » Tue Oct 20, 2009 4:08 pm

Silly question, but ought this discussion be in the "Beginners'" forum? It might scare a true Beginner off!

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue Oct 20, 2009 6:30 pm

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!

Post by **mathdon** » Wed Oct 21, 2009 9:46 am

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

WagonMaster · Post by **WagonMaster** » Wed Oct 21, 2009 12:02 pm

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

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed Oct 21, 2009 2:16 pm

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.

Post by **mathdon** » Wed Oct 21, 2009 3:38 pm

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