protocol-builder v3.12 with integrated assembler available!

[mr_d_p_gumby]

The latest version of the protocol-builder spreadsheet (PB v3.12) is available.

As of version 3.10, PB includes an integrated protocol assembler.

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

This is mostly a maintenance release fixing some bugs in the assembler and disassembler. Changes include:

• Corrected S3C8 disassembly of certain indirect register references.
• Corrected assembled op codes for S3C8 PUSHUI/UD & POPUI/UD.
• Added option to save disassembly as *.asm file.

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.

[The Robman]

• Added option to save disassembly as *.asm file.

Hey Mike, is there any chance that you could build on this option to allow us to save new protocols in the UEI "SRC" format.

Here's a sample SRC file...
http://www.hifi-remote.com/forums/dload ... le_id=2094

That way, when we create a complicated new exec, we can hand it off to them "as is" without them needing to re-write it.

[mr_d_p_gumby]

• Added option to save disassembly as *.asm file.

Hey Mike, is there any chance that you could build on this option to allow us to save new protocols in the UEI "SRC" format.

That's the next item on my list. The first step was to modify my existing code for the diassembler, which is now done.

Of course, it would be much easier if UEI would find a cure for their NIH syndrome and just start using PB!

[The Robman]

Of course, it would be much easier if UEI would find a cure for their NIH syndrome and just start using PB!

"NIH syndrome"

I have been dropping hints to them that they should use PB, but at the end of the day they need to store the execs in their DB in the SRC format, so even if they do start using PB, they would need this new feature to avoid needing to re-type the whole thing.

[mr_d_p_gumby]

"NIH syndrome"

NIH = "Not Invented Here"

[ElizabethD]

It's nice. Thanks.

[*]Added option to save disassembly as *.asm file.

1. HOW?
2. Any chance of reverse process: take s3c8 source into pb and somehow translate to standard syntax for addressing modes
3. There's an untrapped error someplace in the save or close routine. One of those infrequent things, I can't tell yet the exact steps when it happens.

Of course, it would be much easier if UEI would find a cure for their NIH syndrome and just start using PB! .

My sentiments exactly. It's also WADITW syndrome.

[mr_d_p_gumby]

[*]Added option to save disassembly as *.asm file.

1. HOW?

Select *.asm as the file type in the Save As dialog.

2. Any chance of reverse process: take s3c8 source into pb and somehow translate to standard syntax for addressing modes

Translate? (Hmmm. Maybe I could translate all addressing modes into PDP11 syntax.) Anyway, good old copy-and-paste works pretty well, just like with ECC.

3. There's an untrapped error someplace in the save or close routine. One of those infrequent things, I can't tell yet the exact steps when it happens.

OK, I'll be on the lookout for it...

[ElizabethD]

Re #1: oops, Isee it now, thanks

Re #2: What's a PDP11 syntax?
Let me clarify, tell me if I'm wrong (may well be, all this is baffling). This is a disassembly, IR identical:
A6 95 9A CP R95,#9AH
But if I don't have a fallaback of disassembly, or IR to fallback on, and just paste s3c8 code CP R_Mac, AR_MacBuf it has to, and does, get assembled wrong (A4) because I have NO way of knowing it's supposed to be #AR_MacBuf, immediate, without first running the asm and then looking up the instruction code in the Samsung book. Same thing with hex numbers, but there most of the time I can tell from context of bit tests. Does this make sense? Does this change your answer? And let's try for 65xx

[The Robman]

Hey Mike,
There is an IR engine function that is not supported by the current PB. Take a look at the Protocol protocol (exec $005C), this protocol calls for a mid-stream burst formatted using ONE-ON and LEADIN-OFF. (I'm assuming the ON time comes from the ONE burst as both the ONE and ZERO pairs use the same time). Then, instead of calling $0146 to send the signal, they call $0161.

Is this something you could add to PB next time you're playing with it?

Upgrade Protocol 0 = 00 5C (S3C8+) Proton (KM v8.34)
43 8C 11 8B 16 C5 45 08 08 01 09 00 F5 01 09 03
07 7B 8E 10 7C 08 2A 00 00 00 09 8D 01 61
End