protocol-builder v3.10 with integrated assembler available!

mr_d_p_gumby · Post by **mr_d_p_gumby** » Fri Jun 25, 2004 5:10 pm

The latest version of the protocol-builder spreadsheet (PB v3.10) is available. PB now includes an integrated protocol assembler.

It supports all known JP1-compatible remote processors, though support for the P8/740 and M6805-C9 is not as complete as that for the S3C80 and M6805-RC16/18 based remotes.

Changes include:

Added integrated protocol assemblers for S3C80, P8/740 and 68HC05 chips.
Modified UI to allow use of manually assembled protocols on Setup sheet.
Added comments to protocol upgrade block (for IR v5x), and checkbox to enable comments.
Added logic to translate remote type for PB files made with PB versions 1 & 2.
UI modified to give error message when protocol code is too long.
Fixed error in decoder mapping of S3C8 Generic.
Changed upgrade protocol header to indicate (S3C8+) for new-type S3C8s.
Corrected leadout calculations for 6805-RC.
Updated support for leadout overflow bit PF2.6 for S3C8 & 6805-RC.
Other misc UI enhancements.

Notes for existing PB users:

While PB now has an integrated assembler, its use is strictly optional. You may choose to ignore the assembler and continue to use PB in the same manner as before. The assembler has been added mainly to allow advanced users and experts to create and/or modify complex protocol executors.

For those interested in using the assembler, a separate readme file explains its use, and an example PB file is provided.

The PB files created with this version will contain the assembly source & code, if present. However, you can still load these PB files into older versions of PB (and vice versa) without any compatibility issues.

Post by **The Robman** » Fri Jun 25, 2004 7:50 pm

Sounds very impressive, can't wait to play with it. Good work Mike.

jon_armstrong · Post by **jon_armstrong** » Mon Jul 05, 2004 9:09 pm

Mike,

I just had a chance in the last few days to take a look at this. It looks like a big step forward. I would have to exaggerate my knowledge to say I understand it, but I do have some appreciation for what it can do. I am also pleased to see that PB in general is getting more interest in the forums since I have always thought it was a very powerful tool.

Thanks again,

Post by **The Robman** » Wed Nov 17, 2004 12:27 pm

I had forgotten that Mike added the assembler to PB, so I was still doing it the hard way. I just tried it out and it's fabulous! Great work!

Tiny suggestion, could you add # to the symbols used to identify hex, so in addition to $01 and 01H, you could enter #01.

Also, how about a couple of pre-defined constants for the number of fixed bytes (R10) and the number of variable bytes (R11).

I have just loaded updated copies of two of my hand crafted protocols:
Icom_IC-R7000_Ham_Radio_Receiver.txt
Wurlitzer_CD_Jukebox.txt

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue Nov 23, 2004 6:34 pm

The Robman wrote:I had forgotten that Mike added the assembler to PB, so I was still doing it the hard way. I just tried it out and it's fabulous! Great work!

Glad you finally tried it out & liked it.

I've been a bit bogged down with work the past couple of weeks (weekends too & a few all-nighters), so I haven't had time to respond to this post before now.

The Robman wrote:Also, how about a couple of pre-defined constants for the number of fixed bytes (R10) and the number of variable bytes (R11).

Done. (See v3.11 just released.) I also added one for FLAGS (R00). The currently defined names are:

Code: Select all

   Constant   S3C8   S3C8+  6805-RC16/18  6805-C9  P8/740
   --------   ----   -----  ------------  -------  ------
     CBYTES    R11    R11       ---         ---      ---
     DBYTES    R10    R10       $66         $66      $69
     DCBUF     R03    R03       $5A         $5A      $5D
     FLAGS     R00    R00       $57         $57      $5A
     PD00      R12    R12       $67         $67      $6A
     PD01      R13    R13       $68         $68      $6B
     PD02      R14    R14       $69         $69      $6C
     PD03      R15    R15       $6A         $6A      $6D
     PD04      R16    R16       $6B         $6B      $6E
     PD05      R17    R17       $6C         $6C      $6F
     PD06      R18    R18       $6D         $6D      $70
     PD07      R19    R19       $6E         $6E      $71
     PD08      R1A    R1A       $6F         $6F      $72
     PD09      R1B    R1B       $70         $70      $73
     PD0A      R1C    R1C       $71         $71      $74
     PD0B      R1D    R1D       $72         $72      $75
     PD0C      R1E    R1E       $73         $73      $76
     PD0D      R1F    R1F       $74         $74      $77
     PD0E      R20    R20       $75         $75      $78
     PD0F      R21    R21       $76         $76      $79
     PD10      R22    R22       $77         $77      $7A
     PD11      R23    R23       $78         $78      $7B
     PD12      R24    R24       $79         $79      $7C
     PD13      R25    R25       $7A         $7A      $7D
     PD14      R26    R26       ---         ---      ---
     PD15      R27    R27       ---         ---      ---
     PF0       R28    R28       $7B         $7B      $7E
     PF1       R29    R29       $7C         $7C      $7F
     PF2       R2A    R2A       $7D         $7D      $80
     PF3       R2B    R2B       $7E         ---      $81
     PF4       R2C    R2C       $7F         ---      $82
     XMITIR  $0133  $0146     $01AF       $0183    $FF00

'---' above indicates the constant is not defined for that type of remote

The Robman wrote:Tiny suggestion, could you add # to the symbols used to identify hex, so in addition to $01 and 01H, you could enter #01.

That's a problem. All three assemblers use the leading # syntax to denote an immediate (i.e., literal) argument value. The data sheets for all three processors use this convention, and it's sort-of one of those defacto industry standards. Here's an example of the use of #:

Code: Select all

0C 0A   LD  RC0,#10    ;load decimal value 10 into register C0
0C 10   LD  RC0,#$10   ;load hex value 10 into register C0
0C 10   LD  RC0,#10h   ;load hex value 10 into register C0

Without the #, the source will assemble this way:

Code: Select all

08 0A   LD  RC0,10     ;load value of register 0A into register C0
08 10   LD  RC0,$10    ;load value of register 10 into register C0
08 10   LD  RC0,10h    ;load value of register 10 into register C0

... which brings up a minor problem in this file:

The Robman wrote:Wurlitzer_CD_Jukebox.txt

Your source currently assembles this way:

Code: Select all

FF18  68 04     LFF18:  LD   RC6,DCBUF+1    ;Save variable byte for later use
FF1A  E4 FF 03          LD   DCBUF,$FF      ;load variable byte with all 1s
FF1D  F6 01 46          CALL XMITIR         ;send the prefix portion of the signal
FF20  69 03             LD   DCBUF,RC6      ;restore variable byte
FF22  90 03             RL   DCBUF          ;rotate 1st two bits out of fixed byte
FF24  90 03             RL   DCBUF
FF26  E4 A9 1C          LD   PD0A,$A9       ;change lead-out time to 87030 uSec
FF29  E4 FB 1D          LD   PD0B,$FB
FF2C  44 01 29          OR   PF1,$01        ;turn on repeat flag
FF2F  8D 01 46          JP   XMITIR         ;jump to IR engine

I'm sure what you really meant to accomplish was this:

Code: Select all

FF18  68 04     LFF18:  LD   RC6,DCBUF+1    ;Save variable byte for later use
FF1A  E6 03 FF          LD   DCBUF,#$FF     ;load variable byte with all 1s
FF1D  F6 01 46          CALL XMITIR         ;send the prefix portion of the signal
FF20  69 03             LD   DCBUF,RC6      ;restore variable byte
FF22  90 03             RL   DCBUF          ;rotate 1st two bits out of fixed byte
FF24  90 03             RL   DCBUF
FF26  E6 1C A9          LD   PD0A,#$A9      ;change lead-out time to 87030 uSec
FF29  E6 1D FB          LD   PD0B,#$FB
FF2C  46 29 01          OR   PF1,#$01       ;turn on repeat flag
FF2F  8D 01 46          JP   XMITIR         ;jump to IR engine

Note the difference at FF1A, FF26, FF29 and FF2C.

Post by **The Robman** » Tue Nov 23, 2004 9:35 pm

The second decode is the correct one. I noticed that the hex values weren't decoding right for another protocol that I was working on. I tried using $hex and hexH but later found that the only syntax to work was #hexH.

I have another thought. I'm so used to the regular register names (ie, R03, R04, etc) that I'm having a hard time getting used to the DCBUF names. Could you provide a way for me to import/decode an existing protocol and have it get disassembled using the R03, etc names. Right now I end up manually re-typing all of them. Then another button to convert them back to DCBUF names before saving the file would be cool too, so that others can use them.

There's probably a button that already does this, but I tried a few different combinations and couldn't find it.

But like i said before, I really like this and will be using it alot now. A guy called Ian Clowes started writing a web based application like this a while back but I don't think it ever got finished.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed Nov 24, 2004 1:36 am

The Robman wrote:I tried using $hex and hexH but later found that the only syntax to work was #hexH.

#hexH and #$hex should work interchangably. If there's no $ or H, the assembler will assume decimal values. For values less than 10, the hex and decimal values are the same, so you could omit the hex indicators for commonly used values, like zero. If there's no #, then the assembler assumes it refers to an address or register, depending on context.

The Robman wrote:I have another thought. I'm so used to the regular register names (ie, R03, R04, etc) that I'm having a hard time getting used to the DCBUF names. Could you provide a way for me to import/decode an existing protocol and have it get disassembled using the R03, etc names. Right now I end up manually re-typing all of them. Then another button to convert them back to DCBUF names before saving the file would be cool too, so that others can use them.

First of all, using the names is always optional. You can still use the register names and the assembler will be just as happy. So LD RC0,DCBUF and LD RC0, R03 can coexist and will assemble to the same code.

If you uncheck the "Use pre-defined data labels" checkbox, then the assembler will not know the names, so LD RC0,DCBUF will generate an error.

The disasembler also has a similar checkbox. If you uncheck it and re-do the disassembly, then the names will not be used, so you'll get the R03 you crave.

I don't currently have a way to automatically generate the names in the assembler if they are not typed in, though I'll look into the idea.