JP1 Remotes

gfb107 wrote:I've made the requested enhancements. Graham, let me know when your assembler/builder is ready for alpha (or official) release.

Thanks, Greg. It will certainly need to be an alpha. Testing has shown up some issues I need to deal with, so it's not as imminent as I had hoped. Best estimate is sometime next week. I will let you know.

I have uploaded RM/RMIR v2.02 Alpha 12. Greg has made the changes to Import Protocol and to the selection of Primacy that were requested and I have made a first attempt at adding Protocol Builder facilities.

There are bound to be many bugs and other issues with the assembler/builder facilities but I feel that it is time that it got a public airing. Here are some comments on its operation, otherwise just try it and see!

* The assembler listing is editable and has insert/delete and copy/paste buttons. Use Shift/Click to select a rectangular block of cells. The editing buttons work on the entire rows containing the selected block, it is not necessary to select the whole row. "Insert" inserts above the block a number of rows equal to the number of selected rows (just as in Excel). When entering data into the listing, it always maintains a blank row at the bottom, inserting a new one as necessary.

* The data in the Protocol Data, PF Details and PD Details panels are editable. Any change in one panel is immediately reflected in the others, they are always kept in step. Changes, however, are not incorporated into the assembler listing until the Build/Get Data button is pressed. This is a single button with two functions. If there is already protocol code in the assembler panel then the button legend is "Get Data" and it brings the data bytes into line with the data panels. If there is no protocol code then its legend is "Build" and it builds a basic protocol from the data panel info including the necessary assembler instructions.

* In either mode, Build/Get Data does not change the hex data in the Protocol Code panel. To update this with the built/amended protocol you need to press the Assemble button. This generates the hex data and enters the result in the Protocol Code panel as new code (if a new manual protocol is being created) or custom code (if a protocol is being edited) as appropriate.

* The assembler listing is not saved in a .rmdu or .rmir file but it may be saved to, and loaded from, a plain text file with the Save and Load buttons. A saved file has the fields tab-separated but any white space may be used to separate them in a file that is to be loaded. A label needs a colon to terminate it and a comment needs a semi-colon to begin it. These semi-colons do not appear in the RM/RMIR assembler panel but they are needed for parsing and are inserted and removed by the save/load processes.

* The Build/Get Data button operates in two slightly different modes, depending on which tab is selected when it is pressed. If either the PF Details or PD Details tabs is selected then no consistency checking is performed. The intention is that this mode can be used to set the data when assembler code is to be written to make use of the data in some non-standard way. If the Protocol Data tab is selected then inconsistent or missing data will be modified to create a valid protocol. I expect this to be the normal mode of operation.

* The mnemonic labels listed in the Functions tab may be used in assembler code without requiring an explicit EQU directive.

* By default the S3C80 assembler creates S3C8 (old-style) code. To build a protocol for the S3C8+ or S3F8 processor, put an ORG FF00H directive in the listing before running the assembler. This directive is automatically added by the disassembler when it disassembles a protocol it recognises as new-style code.

* The assembler will handle standard arithmetic expressions involving +, -, *, /, % and brackets ( ). The / operation is integer division (remainder is ignored), % is the modulo operation, i.e. it returns the remainder on division. Hexadecimal numbers can be preceded with $ or followed by H or h. Both forms are accepted for all processors.

* Relative addresses are most easily given by using labels, but an explicit form is also accepted in which $ denotes the address of the next instruction, so that for example an S3C80 instructions JR $ - 2 is an infinite loop since JR is a two-byte instruction.

One further comment on S3C80 old versus new code. RM/RMIR automatically converts between the two as required when exporting protocol code, testing the code to see which style it is written for and checking to see which processor version is used by the remote. So it does not matter which processor format a protocol is assembled for, as it will be converted to the one required by the remote concerned when it is used.

I have uploaded RM/RMIR v2.02 Alpha 12a. This corrects a bug in Alpha 12 that prevented certain protocols from loading or disassembling. Apologies, this was due to a late change followed by inadequate further testing.

Alpha 12a also adds one new feature. A line can be commented out of an assembler listing by putting a semicolon at the start of the label field, either on its own if there is no label or before the label if there is one. If you create, outside of RM/RMIR, a text file for loading into the assembler then the semicolon must be the first character of the line in order to comment it out.

A note on creating a new protocol with RM/RMIR. Get Data will only get data from the Protocol Data etc tabs into a protocol that is already properly structured, so if you enter assembler code into the listing grid and THEN try to get the data bytes into it, it won't work. Begin with a basic Build. You can press Build right at the start. You don't need to put the proper, or even any, values into the Protocol Data tab, it will work with just the defaults and you can change the data later. The basic build will give you only one assembler instruction following the data block, JP XmitIR or the equivalent for other processors. Replace this with whatever code you want.

If you forget to do the initial build and have already entered assembler code, use Cut and Paste. Select it all, Cut, then press Build with the empty assembler grid that results, and finally Paste the cut data at the end of the build. After that, you can change the data and use Get Data as required.

gfb107 wrote:I've made the requested enhancements. Graham, let me know when your assembler/builder is ready for alpha (or official) release.

Greg, I have a question on the preserve OBC/Hex selector. Shouldn't that come before the Protocol selection on the screen, or am I misunderstanding how RM works? I thought I'd have to choose what to preserve before I changed protocols, or do we want to put it below, so that most people don't screw things up by changing it when they shouldn't.

Vicky,

You are correct that you must choose what to preserve before changing protocols. You are also correct that most of the time we want to preserve OBC and that I put the Preserve OBC/Hex selector below for that reason.

Maybe it would be better to have an entry in the Options menu "Enable Preserve OBC/Hex" that controls whether or not the Preserve OBC/Hex selector is enabled. If I did that, I would probably move the Preserve selector above the Protocol selector.

vickyg2003 wrote:Greg, I have a question on the preserve OBC/Hex selector. Shouldn't that come before the Protocol selection on the screen, or am I misunderstanding how RM works? I thought I'd have to choose what to preserve before I changed protocols, or do we want to put it below, so that most people don't screw things up by changing it when they shouldn't.

gfb107 wrote: Maybe it would be better to have an entry in the Options menu "Enable Preserve OBC/Hex" that controls whether or not the Preserve OBC/Hex selector is enabled. If I did that, I would probably move the Preserve selector above the Protocol selector.

I like that idea. Defaulting to OBC and having it before the protocol selection. And having it disabled the first time you run RMIR. What do you think about preserving "enable" between sessions? I'd like to save that setting, but again I want it to default the OBC whenever I open RM or RMIR because that is the way it will keep most people out of trouble.

The "Enable Preserve OBC/Hex" option would persist across sessions (in the .properties file), but the actual Preserve setting would not persist.

I've completed the changes to implement this.

Graham, is your assembler/ disassembler getting close to releasable as a beta? I'd like to make a release soon that includes DecodeIR 2.43

gfb107 wrote:Graham, is your assembler/ disassembler getting close to releasable as a beta? I'd like to make a release soon that includes DecodeIR 2.43

Greg, you will have noticed that there have been no comments in the forum on v2.02 Alpha 12 (posted on Oct 7) and the corrected version Alpha 12a posted the next day. This is a deceptive calmness that hides turbulent waters underneath. In the ensuing 11 days, Vicky and I have exchanged 61 e-mails so far, amongst which have been four new versions. I have today received a batch of test results from her, most of which have failed . So no, I'm not ready for a beta release until my sole tester is happy , much as I would like to do so.

OK. I'll wait. I was indeed fooled by the lack of activity here.

mathdon wrote: So no, I'm not ready for a beta release until my sole tester is happy , much as I would like to do so.

When I first read that, I thought you said I was testing your soul.
Perhaps you'll soon have another alpha version so all the other eager testers can join in the fun.

I would be afraid to have my soul tested. It would probably fail because I have no idea how to study for such a test. I'd probably end up extradited to a Internment camp in Seoul where I would have to go through sole training and learn how to quickly snatch a pea from the palm from Rick James.

snatching pee from the palm of Rick James! Oh please take back that image!

The Robman wrote:snatching pee from the palm of Rick James! Oh please take back that image!

OMG, LOL!

While I certainly enjoy painting your imaginations with a full spectrum of words and descriptions. I certainly cannot guarantee its intended spender due to individual perception or interpretation. And, I can only counter with these words, "No take backs!"