10LC Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== FAQ ======
This page covers some FAQs for 10LC.  (Well, not really, because they are not //Frequently Asked// Questions yet, they are just things I thought I should put in here.)

== Why am I getting "Unexpected general exception: The process cannot access the file <FilePath> because it is being used by another process" when I launch the compiler? ==
The primary cause of this is having multiple instances of the compiler running at the same time, and trying to use the same log file path.  If you configured the log file without the ''%#%'' marker in it, the compiler will keep trying to delete and recreate the same log file.  This will fail if another instance of the compiler is still running and using the log file.

== What is this ''Unused40'' I keep seeing when I use the ''TrapErrorMask'' statement? ==
The 9010 unit stores the error mask as a single 8-bit bitmask but it requires bit 6 to always be set when specifying the bitmask.  I do not know what this is, but it is in the documentation, so I followed along.  ''Unused40'' is the name I gave to this must-always-be-on bit, which is ''Unused'' and has a value of ''0x40''. 

== Why does the compiler say that a program was created for ''x'' bytes, but it writes an MRec file that is more than twice that amount? ==
Example:
<code>
Info L0022: Compilation complete, 6 Warnings, 12 programs created, 2036 total PROGRAM bytes
Writing 5292 bytes to <directory>\filename.mrec..
</code>

10LC code is compiled into what the 9010 documentation calls "program steps" which are basically the equivalent of key-presses on the 9010's keyboard.  Each keystroke involved in a program step is a single byte.  However, when this information is converted to MRec format, each byte becomes two printed characters - e.g. a byte with a decimal value of ''142'' gets encoded to value of ''8E'' in the MRec file.  

The setup information is also included in the MRec file and is encoded the same way.  Program numbers and program label information are encoded in the same way, too.  Lastly, the encoded data is broken up into lines, and each line has a checksum field to help detect transmission errors.  All these things contribute to the final (larger) number of bytes that are actually written out to the MRec file.