This is an interesting programming problem that I have come across a
few times, and it is a real pain to fix.
I use DOS's Edit program to develop PIC code and 99.9999% of the time
it works fine. A few times though, the code just stops working as it
is being developed. Of course I think my fingers misinterpreted my
brains wishes and hit the wrong keu, &*^%$# sorry, key.
Anyway this was not the case at all. I traced and tracked and looked
and hacked, until I finally found a line of code that should have
worked but didn't. It even looked ok on screen. I deleted the line of
code from the source file and retyped it exactly as it was and bingo
the code then worked.
Very odd and frustrating. I wonder what little gremlins hide in the
humble Edit progrzm &^%$#(, - flamin' brain.
Tony
Just when I thought I knew it all,
I learned that I didn't.
>I use DOS's Edit program to develop PIC code and 99.9999% of the time
>it works fine. A few times though, the code just stops working as it
>Anyway this was not the case at all. I traced and tracked and looked
>and hacked, until I finally found a line of code that should have
>worked but didn't. It even looked ok on screen. I deleted the line of
>code from the source file and retyped it exactly as it was and bingo
>the code then worked.
I've had this happen to me as well (using other editors like Norton Editor).
I suspect that an errant character gets inserted (possibly due to EMI from
those arc welders next door) into the file. The editor won't display it, but
it gets compiled, causing problems.
Next time save a copy of the file, fix the problem, and then perform a
binary file comparison to see what the offending character is.
>This is an interesting programming problem that I have come across a
>few times, and it is a real pain to fix.
>
>I use DOS's Edit program to develop PIC code and 99.9999% of the time
>it works fine. A few times though, the code just stops working as it
>is being developed. Of course I think my fingers misinterpreted my
>brains wishes and hit the wrong keu, &*^%$# sorry, key.
>
Tony,
DOS "Edit" is a cut down version of the IBM Internal Use Only Editor "E3"
which is notorious for this problem.
Usually the problem can be tracked to a backspace (0x08) character on the
line. You will need a file display utility to actually find the problem.
Before I moved over to MPLAB, I had this problem a few times. The only way
to fix it is to retype the whole line (if you copy the line, the wrong
character and the backspace, which deletes it (and makes it invisible when
you type out the line or look at it in another editor) - which is the error
MPASM is telling you about.
I could go on and explain why this is a problem (MPASM must use FCB file
handling), but that isn't important.
To eliminate the problem you can:
1. Use an Editor other than Edit (or E3).
2. After creating your code, load the file into another Editor and then
save it again (usually the other editor will be able to load the bad
char/backspace and ignore it - like MPASM should). (Big pain in the ass,
it's easier to just retype the line.)
3. Migrate over to MPLAB. (Probably the optimal solution.)
I personally *love* E3/Edit, I have been using it and their predecessors for
literally 15 years. The full version E3 allows you to write Rexx macros
which can be tailored to developing code for different languages and allow
you to directly invoke compilers. I really think it's the best programmer's
development tool available.
But, you will have problems with using it with MPASM. This is why I even
tried MPLAB (because I had a pretty good E3 based development "system"
integrating the E3, MPASM, MPSIM, and MPSTART). The guy who wrote E3 left
IBM a number of years ago (I think about seven) and it hasn't been supported
since then - this problem shows up in very few applications (actually I
consider a bigger one to be the ctrl-Z (0x01A) character put at the end of
each file which shows up as a box in any Windows based
editors/applications). A good question is why IBM/Microsoft ship a program
that they can't support or fix a known bug - I wish I knew the answer to it.
Sorry I can't give you any more help. And sorry for the long missive -
maybe it will help somebody.
Please don't ask for copies of E3 or my "development system", I can't give
them out.
Myke
Do you ever feel like an XT Clone caught in the Pentium Pro Zone?
According to TONY NIXON 54964:
>
> This is an interesting programming problem that I have come across a
> few times, and it is a real pain to fix.
>
> I use DOS's Edit program to develop PIC code and 99.9999% of the time
> it works fine. A few times though, the code just stops working as it
> is being developed. Of course I think my fingers misinterpreted my
> brains wishes and hit the wrong keu, &*^%$# sorry, key.
>
> Very odd and frustrating. I wonder what little gremlins hide in the
> humble Edit progrzm &^%$#(, - flamin' brain.
>
> Tony
Tony:
Probly no gremlins in edit but somewhere between your brain and finger tips.
The best thing to do is a hex dump of the source and look for funny control
chars (beside cr and lf). It is easy to put these things in the file and
they may or maynot be displayable. If you can identify to the line usually
just pressing the arrow keys will expose the char (Its where you have to press
the arrow twice before the cursor moves).
--
Les Troyer
Sr. Analyst
Siemens Power Corp
2101 Horn Rapids Rd.
Richland, Wa. 99352-0130
>... I traced and tracked and looked
>and hacked, until I finally found a line of code that should have
>worked but didn't. It even looked ok on screen. I deleted the line of
>code from the source file and retyped it exactly as it was and bingo
>the code then worked.
>
>Very odd and frustrating. I wonder what little gremlins hide in the
>humble Edit progrzm &^%$#(, - flamin' brain.
Would strongly suspect you managed to embed a control
code into your text. 'Edit' allows you to do this in
a number of ways, and legitimately so.
The problem would then be the behaviour of 'MPASM' on
seeing this code.
> >Very odd and frustrating. I wonder what little gremlins hide in the
> >humble Edit progrzm &^%$#(, - flamin' brain.
>
> Would strongly suspect you managed to embed a control
> code into your text. 'Edit' allows you to do this in
> a number of ways, and legitimately so.
>
> The problem would then be the behaviour of 'MPASM' on
> seeing this code.
Any decent programmer's editor should allow you to embed control characters
in your file, but should make them clearly visible so that you won't leave
them in by mistake. For example, a line with some backspaces would show up
in VI as:
Bill Gates is a monster^H^H^H^H^H^H^Hgenius.
The only tricky issues on PC's are codes zero, 255, and 9 (tab); at least
one betaware assembler I played with would choke on tab characters, so
be aware of them.
In message <D74B0411C8KILLspameng2.eng.monash.edu.au>, TONY NIXON 54964 writes:
>This is an interesting programming problem that I have come across a
>few times, and it is a real pain to fix.
I have had the same thing happen when writing source code and I
think that control codes get typed in by mistake such that they don't change
the appearance of the screen, but do destroy the syntax of the line since
the assembler, C preprocessor, or whatever sees that control code like a red
light and either tries to act upon it or simply gets confused as to what
is supposed to happen. If a copy of the bad source code exists, run
DOS's debug program on it and dump it to the screen, looking for the command
that caused all the trouble. I bet there will be an odd byte or two somewhere
in that line that isn't an ASCII character or also isn't the 0D 0A which
should terminate each line in a DOS text file.
Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group
icom.ca
