I would rather force 16 bit mode and keep the plain '#' reserved for 8 bit use. ... just my thoughts.
I agree. The C32 assembler is non-standard in that regard.
The Kowalski assembler will automatically assemble a 16-bit immediate mode operand if it naturally resolves to 16 bits, assuming the assembler is configured to operate in 816 compatibility mode. By default, I routinely preface an immediate mode operand with !# when I want a 16-bit field assembled, even if it is certain the operand will always resolve to 16 bits. It's my way of making it known to me what the state of m and x is expected to be when that particular code segment is executed.
I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.
I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.
Can you post a copy of the line that caused the error? That way I can trace its path through the code.
I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.
Can you post a copy of the line that caused the error? That way I can trace its path through the code.
thanks!
Daryl
I was afraid you'd ask.
I lost the piece of code that caused the error when I had to forcibly terminate the assembler and now can't recall precisely what it was I did to provoke the problem. However, I seem to recall that the same error could be triggered by passing too many arguments in a macro invocation. I will try that and report back.
So far, that appears to be a C language library generated error vs. an error generated by the simulator. It will take some time to trace down the source.
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"
I have posted the updated files to my website as version 1.3.4.2.
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"
I have posted the updated files to my website as version 1.3.4.2.
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"
I have posted the updated files to my website as version 1.3.4.2.
There is only one Memory window, so can only view 1 range. There is also a separate zero-page display.
If you right click on that window, there is an option to "Display from address", which allows you to enter a specific address. You can also modify memory from here, which is useful for debugging.
There is only one Memory window, so can only view 1 range. There is also a separate zero-page display.
If you right click on that window, there is an option to "Display from address", which allows you to enter a specific address. You can also modify memory from here, which is useful for debugging.
Thanks!
Daryl
Thanks Daryl! And let me be yet another person to thank you for sharing your passion. I won't say "work" because it probably isn't work for you, but all of it is fantastic!
Interesting note. With the assembler now fully understanding the 65C816, I am finding that my code has become more compact and readable due to not having to invoke the macros I had developed to implement 816-specific instructions and addressing modes. This is especially the case with macros with unwieldy names, such as STAILY, which implements STA [<dp>],Y.
Furthermore, assembly is quicker with large programs. For example, POC V1.2's firmware, currently at 12,887 lines of source code, assembles in about a second, with the assembler running on my old Windows XP SP3 machine (powered by an AMD Athlon X2 dual-core MPU). The final version of the firmware that used the 816 macros required about five seconds to assemble. In both cases, the firmware has a bunch of INCLUDE files, which means multiple disk accesses that affect assembly time. That variable hasn't changed, which suggests the assembly performance gain is due to not having to repeatedly look up and expand the 816 macros.
Also very useful are the new pseudo-ops that accomplish things that required macros in the past, such as embedding the assembly date and time, as well as 24- and 32-bit constants. Again, code becomes more compact and readable.
Once again, thank you, Daryl, for expending your time and effort on this software. I'm hoping that having a freely-available 65C816 assembler will encourage others to get involved with the 816 and all that it has to offer.
